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: Chuck Hill <email@hidden>
- Date: Sat, 01 Nov 2003 09:08:27 -0800
Hi Ray,
At 12:38 AM 02/11/2003 +1300, Ray Ackland wrote:
>On 29/10/2003, at 5:46 PM, Chuck Hill wrote:
>>> 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?
>
Not necessarily. Some EOF code will also use this (see Key-Value coding).
I would not assume that it uses storedValueForKey instead of your method.
It is likely to cause you grief and is a bad practice at best.
>Having said that, I see very little
>extra burden creating a second method instead of replacing the one in
>question.
>
A much safer solution. It can also make your code easier to read. Rather
than fiddling with projects() so that it only returns open projects (for
example), you can have methods like:
openProjects()
closedProjects()
projectsInState(ProjectState)
orderedProjects()
etc. Which will make the code much more explicit that using projects() and
hoping the reader of the code remembers that this is not really all the
projects.
>>> 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.
>
Then you may be well advised to stay away from it until you have a real
problem that demands optimization. Caching in eo objects is not a trivial
subject.
Make it right. Then, and only if needed, make it fast.
>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).
>
Yes.
>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.
>
Globla NSArray variable???
>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.
>
An easier, albeit less effective, alternative is to do the filtering and
caching at the UI level. This avoids a lot of problems if you do it at the
form/page level and recache each time a new form/page is displayed. This
way the cache does not hang around long enough to introduce consistency
problems yet reduces the number of time the list is sorted and / or filtered.
Chuck
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
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.