That's deferred fault creation. When deferred faults are used, there is a single fault object that is shared by relationships for a given entity type. When you touch the fault on a specific instance of an EO, it gets replaced by a real (correct) fault object. As far as why it's making a "D", I'm GUESSING maybe C is abstract? Deferred faults have to find the first non-abstract type to instantiate in your inheritance hierarchy (or it couldn't instantiate the fault object). That said, the actual fault object type for a deferred fault doesn't matter that much (well ... that I can think of ... maybe if you're using an EOCustomObject and you're actually storing in an ivar that is typed -- you'd want at least a subtype of the entity or you couldn't store it ... for EOGR, I'm not sure you care) since you never actually "see" it externally. It's not inserted into an EC because it's not a "real" EO -- at least not in the way that you're used to thinking of EO's.
On Apr 6, 2011, at 7:47 AM, Dominique Schoenenberger wrote: > It's not a problem (my application works correctly) but something a little > bit odd for me. > > First here a description of the relationships of interest: > I have a to-many relationship from A to B and a inverse to-one relationship > from B to C (A is a sub-entity of C). > > Here what happens: > When I call the relationship method on an instance of A, EOF do a lot of > things (see trace below): It seams that B objects are created but also ... > the destination object of the inverse relationship ! > (I noticed that because I put a breakpoint in the constructor of C) > > Here some remarks / questions: > 1) Why EOF creates a new object for the inverse relationship. In fact the > destination of the inverse relationship is the calling object, the instance > of A ! > 2) Instead of creating a object of class A as we would have suspected, why > is EOF is creating a object of class of entity D (also a sub-entity of C) > 3) The object created is not inserted in any editing context. I guess it's > a something temporary. > > Is there any means to help EOF like telling which relationship is the inverse > ? > > Dominique > > > Trace: > > D(C).<init>() line: 183 > D(_D).<init>() line: 197 > D.<init>() line: 18 > NativeConstructorAccessorImpl.newInstance0(Constructor, Object[]) line: not > available [native method] > NativeConstructorAccessorImpl.newInstance(Object[]) line: 39 > DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27 > Constructor<T>.newInstance(Object...) line: 513 > _NSUtilities.instantiateObjectWithConstructor(Constructor, Class, Object[], > boolean, boolean) line: 633 > ERXEntityClassDescription(EOEntityClassDescription).createInstanceWithEditingContext(EOEditingContext, > EOGlobalID) line: 242 > ERXEntityClassDescription.createInstanceWithEditingContext(EOEditingContext, > EOGlobalID) line: 754 > EORelationship._deferredFault() line: 1904 > _EODBCtxEntityInfo.computeRelationshipInfoForEntityObjectRow(EOEntity, > Object, NSDictionary) line: 6704 > _EODBCtxEntityInfo.infoForEntityObjectRow(EOEntity, EOEnterpriseObject, > NSDictionary) line: 6744 > EODatabaseContext.initializeObjectRowEntityEditingContext(EOEnterpriseObject, > NSDictionary, EOEntity, EOEditingContext) line: 2228 > EODatabaseContext.initializeObject(EOEnterpriseObject, EOGlobalID, > EOEditingContext) line: 3581 > ERXObjectStoreCoordinator(EOObjectStoreCoordinator).initializeObject(EOEnterpriseObject, > EOGlobalID, EOEditingContext) line: 597 > ERXEC(EOEditingContext).initializeObject(EOEnterpriseObject, EOGlobalID, > EOEditingContext) line: 3768 > ERXEC.initializeObject(EOEnterpriseObject, EOGlobalID, EOEditingContext) > line: 1141 > EODatabaseChannel$_EODatabaseChannelFetchResult.initializeObjects(NSArray, > EOEditingContext, EODatabaseContext) line: 496 > EODatabaseContext._objectsWithFetchSpecificationEditingContext(EOFetchSpecification, > EOEditingContext) line: 3090 > EODatabaseContext.objectsWithFetchSpecification(EOFetchSpecification, > EOEditingContext) line: 3195 > ERXObjectStoreCoordinator(EOObjectStoreCoordinator).objectsWithFetchSpecification(EOFetchSpecification, > EOEditingContext) line: 488 > ERXEC(EOEditingContext).objectsWithFetchSpecification(EOFetchSpecification, > EOEditingContext) line: 4069 > ERXEC.objectsWithFetchSpecification(EOFetchSpecification, EOEditingContext) > line: 1206 > EODatabaseContext.objectsForSourceGlobalID(EOGlobalID, String, > EOEditingContext) line: 4084 > ERXObjectStoreCoordinator(EOObjectStoreCoordinator).objectsForSourceGlobalID(EOGlobalID, > String, EOEditingContext) line: 634 > ERXEC(EOEditingContext).objectsForSourceGlobalID(EOGlobalID, String, > EOEditingContext) line: 3923 > ERXEC.objectsForSourceGlobalID(EOGlobalID, String, EOEditingContext) line: > 1169 > EODatabaseContext._fireArrayFault(Object) line: 4245 > EOAccessArrayFaultHandler.completeInitializationOfObject(Object) line: 77 > _EOCheapCopyMutableArray.willRead() line: 37 > _EOCheapCopyMutableArray.objectEnumerator() line: 96 > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.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: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
