I missed the beginning of this thread, but the memory / attributes problem you describe was a problem in the original photo product, which has been fixed in Ron Bickers' newer product. seb On Wed, 2001-12-19 at 11:11, Toby Dickenson wrote:
On Wed, 19 Dec 2001 10:00:16 +0100, Peter Bengtsson <mail@peterbe.com> wrote:
But they are just references, right? References to the objects. I can't just use objectIds because the returning list I want to sort by a property on the photoobjects.
Does your script use any attributes from the photo object? any at all? if so, all of its attributes are loaded into memory.
Im not sure how the photo product works, but if the photo data is stored as an attribute of the *same* object then this explains the memory growth.
The best way to avoid this problem is to store the photo metadata in a separate persistent object from the bulk data, allowing the metadata to be loaded into memory separately from the bulk data.
Ive not looked at the photo product, but it possibly could (and probably should) be doing this itself anyway.
If thats not how the Photo product works, you could create your own folderish object for storing your photo metadata. Lets call it a PhotoFrame. Each PhotoFrame then contains a single Photo instance.
I hope that helps