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: email@hidden
- Date: Mon, 03 Nov 2003 11:29:59 CDT
- Priority: 3 (Normal)
[demime could not interpret encoding binary - treating as plain text]
On Sat, 01 Nov 2003 09:08:27 -0800 Chuck Hill wrote:
> >> 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.
I've thought about this before, and although I haven't tried it yet, a
trivial solution occured to me. Assuming your filtering/ordering takes
place in _another_ method, which I agree is best, can't you just put some
cache-invalidating code in the actual relationship manipulation methods?
I believe that regardless where the change comes from (developer code,
notifications, etc) the relationship manipulation cover methods will be
executed. True?
public NSArray filteredRelationship() {
createFilteredArrayIfNeccesary();
return filteredArray;
}
public void addToRelationship(EOEnterpriseObject o) {
filteredArray = null;
//followed by usual standard relationship manipulation code
}
Would this work? Just uncache your data whenever the relationship is
modified, by putting the uncaching code in the relationship manipulation
methods? [You could make this more efficient by merging the new object
in, instead of uncaching the entire list. Similar for
removeFromRelationship method. But that's trickier, and it's probably
good enough to just uncache the whole list].
--Jonathan
>
> 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.
_______________________________________________
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.