Re: EO Caching (2)
Re: EO Caching (2)
- Subject: Re: EO Caching (2)
- From: Paul Hertz <email@hidden>
- Date: Tue, 11 Dec 2007 11:32:20 -0600
At 6:11 PM +0100 12/11/07, Alexander Spohr wrote:
Am 11.12.2007 um 16:11 schrieb Paul Hertz:
I think the major culprits in the code are 1) repeated calls to
ec.objectsWithFetchSpecification (a separate fetch for each
question, repeated rather than cached),
Could you fetch all questions belonging to one survey? Cache the NSArray then.
Can do and have done for another tool that output data to a file.
It's what I want to do here, too, but the EOAndQualifier filtering
problem gets in the way. I should probably post the code--will do so
in a bit.
and 2) faults fired one at a time on the fetched rows.
If you have a loop (or WORepetition) (batch)fetch the related
objects before the loop. All relationships will be complete and do
not need to be refetched.
The only relationship I need it the problematic flattened one. Will
see if your suggestions below bring some results.
Perhaps 3) statistical calculations performed on the answers to
each survey question slow things down significantly, too.
Hm.. what could I suggest? Don't calculate, or calculate with another app ;)
Create a new table for stats calculated/updated when writing to the
database, maybe? A strategy I've used quite well in the past--no
calculation needed for the report page.
An additional problem is an EOAndQualifier that correctly filters
rows in a fetch but not in memory (filteredArrayWithQualifier).
Until I figure that out, I have to fetch answers for each question
separately--but at least I can eliminate repeated fetches for the
same question.
Could you do a GROUP BY HAVING? Not sure what kind of fetches you want here.
Or maybe a simple batchFetch for the answers-relationship would do?
Faults only need be fired on multi-choice questions with multiple
answers, which are accessed through a flattend relationship.
Flattened relationships (apparently) do not get pulled in through
batch fetching--the relationship has to operate on a concrete field
of the entity one is fetching. So, batch fetching may not be a
solution (modifyng the databse may be).
Just batchFetch through the n:m-relationship to the target-table?
You just need to get the answers into memory, EOF does the rest (in
the same EditingContext)
Performing the fetches and statistical operations, etc., in a
threaded task in a WOLongResponse page, rather than having bindings
in the html/wod files trigger calculation, should provide a
reasonable solution to preventing timeouts, if not to speeding
things up. Even if the page still takes a long time to build and
load, the client will see some sort of progress indicator.
Is it possible to set up a second app for this? Or pre-calculate and
deliver html?
That is a question to which I'd love to have an answer! I don't think
a separate app would be needed, just a thread that handled the page
generation. I don't yet know how to capture the HTML a WOComponent
generates--maybe the Collective Wisdom does?
Finally, our WO server and our DB server are separate machines.
Possibly there are deeper-seated problems with the synchronization
of calls and database locking, but I'm going after the low-hanging
fruit first.
No, the database will be fast enough as long as you don't fetch a
million records or poke it to death with single object fetches.
atze
Freeport & Soliversum
Alexander Spohr
email@hidden
www.freeport.de
--
Paul Hertz <email@hidden>
|(*,+,#,=)(#,=,*,+)(=,#,+,*)(+,*,=,#)|
<http://collaboratory.nunet.net/phertz>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden