Re: EOF create object (temporary ?) for the destination of an inverse relationship
Re: EOF create object (temporary ?) for the destination of an inverse relationship
- Subject: Re: EOF create object (temporary ?) for the destination of an inverse relationship
- From: Mike Schrag <email@hidden>
- Date: Wed, 06 Apr 2011 08:55:47 -0400
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@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden