Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Filtering array returned by an EO's relationship (D2J)

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.
References: 
 >Re: Filtering array returned by an EO's relationship (D2J) (From: Chuck Hill <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.