Re: Filtering array returned by an EO's relationship (D2J)
Re: Filtering array returned by an EO's relationship (D2J)
- Subject: Re: Filtering array returned by an EO's relationship (D2J)
- From: Ray Ackland <email@hidden>
- Date: Sun, 2 Nov 2003 00:38:17 +1300
On 29/10/2003, at 5:46 PM, Chuck Hill wrote:
Hi Ray,
My current stage is replacing the standard call for
storedValueForKey()
with a specific objectsWithFetchSpecification() using the desired
target entity, and qualifiers for the related record I am calling
from,
along with my filter qualifier.
I'm not sure I understand. If you are adding a new method to do this,
then
OK. If you are replacing a generated method (representing a
relationship
in the EOModel) that uses storedValueForKey(), well then you are
asking for
grief and EOF will eventually give it to you. Pick a different method
name.
This part I'm not very confident with. I was replacing it with the
newly devised one. But isn't the generated method that calls the
storedValueForKey method just a convenience method for other routines
you use, to simplify your code? Having said that, I see very little
extra burden creating a second method instead of replacing the one in
question.
Seems to work, and only requests the
objects I want (rather than getting all first and then filtering). I
also have put in a conditional that the NSArray I am fetching into is
null so I don't repeatedly do the fetch.
Sounds like a good optimization if...
My only concerns are that I may be missing out on some WO magic, such
as the fetched array being refreshed (seems ok in testing though) and
that the EOEditingContext recognises the relationship between the
source and destination objects.
... you make sure to null this array out when things change. With a
regular WO app and attributes this is not too much of a problem.
Caching a
to-many relationship makes it much harder and I've no idea what
oddities
D2JC might throw into the mix.
If you are not using the default editing context and creating new
editing
contexts on a form by form basis you will probably be OK with what you
are
doing. Otherwise, imagine object A caching part of its to-many
relationship B. One of the B objects changes and because of that
change
should be added to or removed from the cached array. Object A has not
changed so no methods are going to get called on it that would allow
you to
release the cached values. You will also have to contend with objects
being added to or removed from the B relationship. All of this
situations
may occur in the same and other editing contexts.
Catching notifications is probably the best way to go about it. See
the
EOEditingContext docs for relevant notifications.
To say I am not too confident with this part would be an
understatement. I am using the same editing context that the source
entity belongs to (figured I needed to do this so source and
destination objects in same context). Also, the entity whose global
NSArray variable this is (for the destination of the to-many
relationship) gets released whenever the window is closed, helping with
one aspect.
While things do go ok when changes are applied to existing destination
entities, I do see that it is quite possible for new records to be
created, or ones deleted, that won't be reflected in the cached
relationship. I should look at some way of checking for that (if I
continue on this path) - probably by the
ObjectsChangedInEditingContextNotification approach.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.