Re: can I use fetch spec to filter an array?
Re: can I use fetch spec to filter an array?
- Subject: Re: can I use fetch spec to filter an array?
- From: Jonathan Rochkind <email@hidden>
- Date: Tue, 30 Dec 2003 18:33:21 -0600
At 1:22 PM +1300 12/31/03, Denis Stanton wrote:
They are likely to run this report to cover either a six month or
one year period. The speed problem only becomes apparent for the
one-year report. That means a lot of bookings in memory so I was
attempting to process one agent at a time.
If neccesary, you could come up with SQL to generate the summary and
calculated fields neccesary for your report. Then run the SQL
directly with EOUtilities.rawRowsForSQL, from which you just get
NSDictionary's of key/values, which you process to make your report.
Assuming that you can come up with SQL that does most of the hard
work, and is processed relatively quickly by the db (that's what a db
is good at, after all).
In general, I consider such a raw SQL solution to be a last resort.
But if you can't make it work with tolerable performance any other
way, it's definitely appropriate. Calculation-intensive reports are
probably the most appropriate place for raw SQL, when neccesary.
Not that I'd neccesarily give up on doing it with actual EO objects
yet; I have no opinion on that, it's up to you.
Another thing to consider: if an Agent has a to-many relationship to
Booking, and there are a HUGE number of bookings at the destination
of a particular relationship, only a small subset of which you are
actually interested in---then don't use the relationship. Instead
actually fetch these bookings yourself with an EOFetchSpecification,
fetching only the bookings you are interested in, within (or even
accross) a particular agent. You may already be doing that, apologies
if I'm stating the obvious.
Hope this helps,
--Jonathan
You could start fetching daily sets of data and getting aggressive
with EOF memory management to control this.
Any hints about getting aggressive with EOF memory management would
be of interest.
My report uses a simple repetition to work through the agent array.
DisplayList: WORepetition { list = agentArray; item = agent;}
Then I have a setAgent method that is implicitly called by the repetition.
protected void setAgent(Agent inValue) {
bookings() = new NSMutableArray(
EOQualifier.filteredArrayWithQualifier(agent.bookings(), qualifier) )
}
The repetition encloses lines with values mapped to @sum
calculations on the bookings array
String1: WOString { value = email@hiddenrice; }
I am assuming that since the setAgent() method recreates the
bookings array for each agent then Java will take care of the memory
management, keeping just one agent's bookings in memory at a time.
Once you have all the bookings, you can get all the agents from:
NSArray agents = new
NSSet((NSArray)bookings.valueForKey("agent")).allObjects();
Then run a loop over all the bookings, tell the agent to calculate
stats for them:
thisBooking.agent().accumulateStatsFor(thisBooking);
You will probably also want a resetStats() method to zero these out.
You will need to add instance variables to Agent to hold the 11
totals. Don't put these in the EOModel, they are just transient
values for reporting. The code to determine which booking affects
which stat goes in Agent. This keeps the functionality fairly well
partitioned and keeps processing time down as you have a minimal
number of fetches and touch each booking once in one loop.
Following this, sort the list of agents and report away!
Do you see an advantage in accumulating into instance variables in
each Agent, then sorting and printing, as opposed to sorting the
agents first (I specify the sort in the fetch) and then calculating
and printing one line at a time by defining the display as for
String1 above?
"Extract - (calculate) - Sort and Print" seems more like the way I
used to work in the pre-OO days (I was a Cobol programmer for 15
years). I have been trying to avoid storing calculated values when
the calculation itself can be defined as an instance method.
HTH
BTW. What is HTH? Happy "T" Holiday?
Denis
Denis Stanton
email@hidden
Home: +64 9 533 0391
mobile: +64 21 1433622
_______________________________________________
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.