You might be thinking of Core Data - they REALLY want you to have back pointing relationships in Core Data…
On Mar 10, 2015, at 12:48 AM, Chuck Hill <[email protected]> wrote: > > > 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]> wrote: > > Chuck, > On 5. 3. 2015, at 18:44, Chuck Hill <[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/kenlists%40anderhome.com > > This email sent to [email protected]
_______________________________________________ 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]
