On 19 Apr 2007, at 14:57, Frank Stock wrote:
Ken,
what I don't understand is why all the relation-rows are fetched,
not just the selection thats needed?
A <--->>>> B
A has an array fault; if you touch it, EOF will go to the database to
get all B belonging to A.
If you do a.addObjectToBothSidesOfRelationshipWithKey(newB, "toB") ,
then EOF will look at toB to see if newA is already in it, and this
will cause the fault to fire and all the objects will be fetched.
Similarly, when doing a.removeObjectFromBothSidesOfRelationshipWithKey
(oldB, "toB") EOF will look at toB to remove oldB from it. This sort
of thing happens even without a back-pointing relationship.
If you were writing SQL yourself and managing the relationships
yourself, you would be able to insert newB or delete oldB, and make
the SQL, and you would know that you didn't need to fetch the objects
for toB. EOF cannot be quite that clever. EOF knows some rows are
to be fetched, but not why, so cannot do something special and
different and efficient.
That's where the ObjC code I posted came in. I can be that that
clever, so I know that if, inside a bit of my code using an
editingContext, EOF asks for a particular fetch to be made, I can
intercept that, and instead of returning an array of objects from the
database, I can return an array of objects already in the
editingContext without any fetching.
Look at http://developer.apple.com/documentation/WebObjects/Reference/
API/com/webobjects/eocontrol/
EOEditingContext.Delegate.html#editingContextShouldFetchObjects
(com.webobjects.eocontrol.EOEditingContext,%
20com.webobjects.eocontrol.EOFetchSpecification) .
I'm not rewriting that ObjC code as Java until I need to!
-- Patrick
_______________________________________________
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:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
