Well, with all this discussion going around I am very grateful for the
thread organisation stuff in Panther's Mail programme! I would like to
thank everyone for the contributions they are making. It is providing
me with many paths to follow and lessons to learn. I just hope that I
can pass the benefit on to others in the years to come.
Just to bring everything into one place (for my benefit, as much as
anyone's) here is how things stand at the moment:
1) I am developing a Direct to Java application (D2J). In the database
exists thousands of records (time sheet items) related to each "main"
entity that I am dealing with (a staff member).
2) Because the main window (for the staff member) has a pane to display
their time sheet details, all the related records are getting retrieved
from the database, sent to the Java client application, and turned into
custom enterprise objects. This is taking an unfriendly amount of time,
as well as overwhelming the user with irrelevant information.
3) There are 4 approaches I know of at this stage that can be
implemented in the staff class (and using a separate method from the
standard get method):
a) retrieve all the related records using the standard method, then in
the client filtering using filteredArrayWithQualifier.
b) do the filtering on the server app, then sending these to the client
all via a remote method invocation.
c) using an custom fetch to retrieve only the wanted records from the
database.
d) using an auxiliary qualifier to affect the standard fetch so only
the desired ones are returned, and WO still provides all the normal
"relationship support work".
Option a) works well, apart from it taking even longer (all records are
still sent to the client).
b) is looking to be the lead horse at this stage, but I would really
like to use a method in the client rather than the server as (to me) it
makes the process more transparent.
c) what I have been using so far, but leaves me with possible problems
regarding caching and updating of records (I have to provide the
magic).
d) sounds like a great solution - if only I knew how to work it. The
problem being (as far as I can tell) I am not working with a display
group (don't know what happens through the storedValueForKey() method)
and don't know how to acquire the EODataSource that the standard
relation methods use. If I just create myself one and attach an
auxiliary qualifier, how does that differ from my custom fetch method?
At this point, I think that I have enough information from everyone
that I can produce a solution - even if not the most efficient one.
Would be nice if there were a way just to attach a qualifier to the
standard fetches so it were like programmatically setting the qualifier
field in the Advanced Entity Inspector in EOModeler. This would be like
automatically removing the older entries from the system - but still
having them available to other models and historic purposes.
But once again, thank you all for the time, effort, and energy you have
dedicated to helping me with this problem.
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.
