On 2015-03-09, 12:03 PM, "OC" wrote:
Hmmm... I have possibly found the culprit. Some time ago when optimizing, I have removed a number of unused (and big) 1:N relationships, leaving just the small and fast inverse ones. (Incidentally... does my memory play tricks on me, or there really used to be a time when a relationship without an inverse in EOF was a big no-no?) Not that I recall. Missing relationships can prevent EOF from processing some complex qualifiers (I think) but you can just model them and make them not class properties so that EOF has access to the modelling information. Chuck Looks like one of the removed relationships has been an EODeleteRuleNullify one; without the nullification, in some (pretty rare) cases it was possible that of two newly inserted objects in relationship one was deleted, whilst the other remained, and it seems this sometimes might lead to this case -- possibly. (Definitely it sometimes led to "Cannot obtain globalId for an object which is not registered in any editingContext" problem when saving, this I am sure of. The more esoteric bug with faults and NPEs, outlined below, I alas was not able to track fully.) Thanks a lot for all the help! OC On 5. 3. 2015, at 18:55, OC <[email protected]<mailto:[email protected]>> wrote: Chuck, On 5. 3. 2015, at 18:44, Chuck Hill <[email protected]<mailto:[email protected]>> wrote: It might happen if you have a temporary GID. Are you using parent and child editing contexts? Nope, at the moment I am using peers only. (But I intend to switch to nested ECs in new version for object creator/editor pages, which at the moment I do in session default EC and it is not good. Are there some non-obvious gotchas with nested ECs?) Nevertheless I _do_ put just-created objects with temporary GIDs into relationships, and it looks like there would be some problem in there perhaps :/ Thanks and all the best, OC On 2015-03-03, 2:47 PM, "OC" wrote: Hello there, in my latest log, there is (thrice) a NPE at at er.extensions.eof.ERXDatabaseContextDelegate.batchFetchToOneFault(ERXDatabaseContextDelegate.java:714) Looks like it's here: === private synchronized boolean batchFetchToOneFault(EODatabaseContext dbc, AutoBatchFaultingEnterpriseObject eo) { if(fetchingToOne.canEnter(dbc)) { try { EOGlobalID sourceGID = eo.batchFaultingSourceGlobalID(); String key = eo.batchFaultingRelationshipName(); if(sourceGID != null && key != null) { EOEditingContext ec = eo.editingContext(); AutoBatchFaultingEnterpriseObject source = (AutoBatchFaultingEnterpriseObject) ec.faultForGlobalID(sourceGID, ec); EOEntityClassDescription cd = (EOEntityClassDescription)source.classDescription(); // 714 ... === Looks like 'source' must have been null. Can faultForGlobalID return a null?!? When would that happen? Thanks, OC
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
