netProphET: after updating my XML and regenerating the PHP class/maps, that’s when performance started suffering. So no, it’s not directly related to the XML, but it does seem that defining more (or incorrect?) relationships has something to do with it.
Jason: Yeah, unfortunately, there are some cases where I’m using getOne inside of a loop (don’t know how else to handle it, frankly -- maybe it’s time to use the getCollectionGraph). E.g. I’m listing all rows from a custom table -- the db table by itself is not human readable, so I need to track down some of the foreign keys in order to list the human-readable columns inferred by the foreign keys.
BUT that’s not the area where performance is suffering, oddly... I’m not using the getCollectionGraph or getObjectGraph methods yet. Some of these relationships are difficult to work with if you retrieve more than a layer deep, you know? E.g. if you join on a related table, which in turn contains foreign keys, then it starts getting wonky.
Mostly, it’s a lot of stuff like this:
$tf = $modx->getObject('Trackingforms', $trackingform_id);
$forms_resources = $tf->getMany('Resources');
foreach ( $forms_resources as $fr )
{
$resource_id = $fr->get('resource_id');
// ... do stuff ...
}
I’ve got a version of this working (albeit slowly) but I think I’d better give it a round 2 and approach it from a more architecturally sound way. Hard to explain exactly what I mean, but I’ve created a form that is perhaps easier for the user, but is not so "honest" as far as what’s in the database. I have a feeling that round 2 will be considerably faster.
☆ A M B ☆
MODX Staff
MODX Staff
