Well, I figured out the problem.
In Practical WebObjects on page 44 Chuck and Sacha recommend as one
possibility moving the LOB data into a related entity. They say that
"This allows you to avoid faulting in the LOB until you need it".
When I fetch my entity, the LOB table is included, not faulted as I
was expecting. This is why I am running out of memory.
It turns out that a derived attribute that I was using to search the
LOB combined with other fields in the main artifact (using the
coalesce function) caused the LOB to be loaded into memory behind the
scenes with each record. Not good for performance. I am going to
implement the search as individual search fields instead. The Google
simulation will have to wait for another day!
David
On 18-Sep-07, at 1:39 PM, David Holt wrote:
Hi,
I have recently solved an out of memory problem in a list page by
using a batching display group that just fetches one page worth of
records at a time.
Now I find that creating an object from that page is once again
trying to fetch every record in the data table prior to allowing me
to save changes. Is there some way around this? I understand that
EOF wants to ensure that I haven't already created that object, but
is it necessary to load the entire table into memory? Thanks,
David
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/programmingosx
%40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
