Multiple instances of getCollectionGraph fails?

I don’t know if it’s my whacko code, but I seem to reliably make my PHP system explode by using getCollectionGraph more than once in my custom manager page. My poor PHP log file has been byte-slammed with lots of these warnings:



I didn’t realize I had multiple instances of this, so I’ll be fixing that, but I thought it’d be worth inquiring about this here.

You’re just simply running into a resource wall, trying to load up a large collection.
You’ll have to find a way to optimize it. One way is by removing stuff from your collection graph and iterating a collection (e.g. of related objects) where you can with getIterator. Although getCollectionGraph is mighty handy, you might have to break it down into a combination of getIterators.
There is no getIteratorGraph yet.

Quote from: netProphET at Jan 12, 2011, 03:32 PM

Although getCollectionGraph is mighty handy, you might have to break it down into a combination of getIterators.
There is no getIteratorGraph yet.

LOL — yet he says...

see:
http://modxcms.com/forums/index.php/topic,61283.msg349192.html#msg349192

LOL — yet he says...

until there is - can you please suggest an optimized way to do this?
(without doing getOne/getMany for each record..)

you might have to break it down into a combination of getIterators

Meaning - doing X number of getIterators and combining them to one array (or xpdo object?) each time?
where X = main class + xx child classes

thanks

The optimized way is to build a query using joins to your related classes that gets exactly the data you need in the result set and then manually iterate it (i.e. fetch() each row) to collect the data for output or whatnot. This gets complex with many different kinds of relations involved and at some point you have find other approaches to the problem. Not sure it’s something one can solve generically.

Otherwise, you might find another approach to solving the problem, maybe by de-normalizing your model a bit for optimized access for your presentation requirements, or creating de-normalized summary tables for this purpose which get populated on save of the normalized tables.

creating de-normalized summary tables

Thanks jason.
This is how i currently resolve that. unrelated to xpdo, i need high performance for ’real-time’ filtering on complex data sets.
rows are individually updated on objects save() and remove()
my only issue is actually with the flush(), as it goes through the complete set to generate the optimized tables (which are currently simply cached via xPDOFileCache).
although, it is not a big issue, as flush() only happens after cache-cleanup or on error - both are not common..
as long as getIteratorGraph is ’yet’ to exist, I guess it simpler to resolve that by doing a LIMIT’ed getCollectionGraph multiple times (1-2k each time).


when getIteratorGraph arrives - please announce this with bold tags in the github commit message.
i’m "heavily invested" in an xpdo schema with a lot "to-many" relationships - getCollectionGraph is very nice for that. (compared to join’ing..)

thanks again.