Hi there,
pretty rarely, but alas repeatedly — something like, twice a year — our clients
observe a weird behaviour that
- they add “a row to a table”, means an eo into a standard 1:N relationship;
- immediately after that, they do not see the newly added row in the GUI, nor
do see it newly logged-in users, means their table.rows relationship does not
contain the new one;
- in awhile, or if the app happens to be restarted, immediately after the new
launch, the problem disappears.
Not surprisingly, so far we haven't found any way to trigger the problem
intentionally :(
We have never observed similar problem with other relationships — which might
just as well mean it never happened, or that it does happen too, but just never
got noticed so far :)
I went repeatedly through the logs and so far found no reliable explanation,
but eventually it occurred to me if
ERXEnterpriseObject.updateInverseRelationships (which we use to keep all our
relationships in sync) happened to fail somehow, it would, I believe, cause
precisely the observed behaviour: the new object would be set up all right, it
would get its proper :1 relationship to the table (the appropriate FK would be
set and eventually saved to the DB all right), but the table's :N inverse, for
some weird reason, would not get updated to contain the new object. New
sessions (well all new ECs whichever way they are created) would get the wrong
(not-updated) relationship from table to rows from the to-many snapshot, until
the EC timestamp lag times out. When it does (or when the app gets relaunched),
the relationships gets re-fetched from the database, which fixes the problem.
My primary question is, has anybody lately observed any problems with
ERXEnterpriseObject.updateInverseRelationships reliability?
The other question is, I am considering to change my current straightforward
row object code
void setTable(DBTable table) {
takeStoredValueForKey(table,'table') // setting the :1 relationship,
trusting Wonder to sync the inverse
}
to this ugly contraption, which — or so I hope! — might catch the problem the
next time it happens and attempt to fix it immediately:
void setTable(DBTable table) {
takeStoredValueForKey(table,'table')
if (!(this in table.records)) { // the inverse :N was not updated?!?
Log.warn "Something wrong with updateInverseRelationships!!!"
EOObjectStoreCoordinator osc=this.editingContext.rootObjectStore
EOEntity
entity=EOModelGroup.modelGroupForObjectStoreCoordinator(osc).entityNamed(this.entityName)
EODatabaseContext
dc=EODatabaseContext.registeredDatabaseContextForModel(entity.model(), osc)
dc.lock()
try { dc.database.forgetAllSnapshots() }
finally { dc.unlock() }
Log.warn "having re-fetched, now seems OK: "+(this in table.records)
}
}
Can you perhaps see a problem with that code, or would you suggest another
approach? Am I right that database.forgetAllSnapshots() is safe in the sense
that no data (including changes in ECs not yet saved) would be lost?
Thanks!
OC
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
