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 10:42:31 +1300
Chuck, I'm sure I can hear you cringe when you read many of these
postings. I am amazed you get the time (& energy) to answer as many
people's cries as you do.
On 2/11/2003, at 6:08 AM, Chuck Hill wrote:
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.
Yeah, I agree. In fact I had decided that I should put an option in the
UI to let the user choose whether to filter or not. Having multiple
methods would be better for this too.
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.
Perhaps a modification to that: Make it right, then make it fast. Then,
and only if needed, add more features (unless Bill pays your wages :)
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.
Global NSArray variable???
Yes. The NSArray which is holding the destination objects. Global, as
in terms of defined outside the method that does the fetching. Or I
could (should?) have said local to the class. I have done this so it
will have a life span similar to that of its enclosing object (which is
around as long as the form window).
If I had made it local (to the method), it would always be refetched
when referenced. If static, it would be shared between other entity
instances and cause complications. Is there a better alternative (I am
here to learn)?
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.
Well, that was the original problem - I am only wanting a small subset
of the full number of records. Sending all the data to the client, and
converting them to EO objects was quite time consuming. Talking about
minutes here - and that is with database, server and client
(development stage) on the same machine. This is something that a web
application has an advantage in.
Ray.
_______________________________________________
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.