Looking at line 4205 in EODatabaseContext, it looks like it calls the delegate’s databaseContextFailedToFetchObject() method before the gid is added to the _missingObjectGIDs set in _fireFault().
http://wocommunity.org/documents/javadoc/WebObjects/5.4.2/com/webobjects/eoaccess/EODatabaseContext.Delegate.html#databaseContextFailedToFetchObject%28com.webobjects.eoaccess.EODatabaseContext,%20java.lang.Object,%20com.webobjects.eocontrol.EOGlobalID%29 This is the only place where I can see GIDs added to that set. Which is puzzling, because the default behavior in wonder is to throw an exception at the point that happens. Have you set the property er.extensions.ERXDatabaseContextDelegate.tolerantEntityPattern or supplied your own EODatabaseContext delegate to override Wonder's? Have you called _fireFault() and swallowed the exception? Otherwise, at a quick glance, I don’t see the code path that lands where you are. On Feb 5, 2015, at 4:22 AM, OC <o...@ocs.cz> wrote: > Sorry I've sent too soon; I wanted to add... > > On 5. 2. 2015, at 12:19, OC <o...@ocs.cz> wrote: >> well I must have some pretty weird bug somewhere. Does anybody have any idea >> what dumb fault of mine might cause >> >> === >> Caused by: com.webobjects.eoaccess.EOObjectNotAvailableException: >> prepareForSaveWithCoordinator: Cannot save the object with globalID >> _EOIntegralKeyGlobalID[DBDFPrototype (java.lang.Integer)1000022]. The row >> referenced by this globalID was missing from the database at the time a >> fetch was attempted. Either it was removed from the database after this >> application got a pointer to it, or there is a referential integrity problem >> with your database. To be notified when fetches fail, implement a delegate >> on EODatabaseContext that responds to databaseContextFailedToFetchObject(). >> at >> com.webobjects.eoaccess.EODatabaseContext.prepareForSaveWithCoordinator(EODatabaseContext.java:5657) >> at >> com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditingContext(EOObjectStoreCoordinator.java:370) >> at >> com.webobjects.eocontrol.EOEditingContext.saveChanges(EOEditingContext.java:3192) >> at er.extensions.eof.ERXEC._saveChanges(ERXEC.java:1179) >> at er.extensions.eof.ERXEC.saveChanges(ERXEC.java:1102) >> at er.extensions.eof.ERXEC$saveChanges$8.call(Unknown Source) >> at >> cz.ocs.model.OCSEnterpriseObject._saveTolerantlyChangesInEC(OCSEnterpriseObject.groovy:520) >> // ec.saveChanges() >> === >> >> given the appropriate row definitely does exist in the database? (I have >> checked and re-checked; it is there, and it has still its original creation >> timestamp two-odd years old.) > > ... that I have bumped into similar problem before, and we have suspected it > was caused by superfluous (and probably harmful) object locking. No locks in > there anymore, I've removed them: > > http://prod.lists.apple.com/archives/webobjects-dev/2015/Jan/msg00161.html > > 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/rgurley%40smarthealth.com > > This email sent to rgur...@smarthealth.com _______________________________________________ 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
