Performance issue with getParent and maybe other things

[dantleech]

I noticed that if you map the @ParentDocument it seems that the parent node is eagerly loaded:

https://github.com/doctrine/phpcr-odm/blob/master/lib/Doctrine/ODM/PHPCR/UnitOfWork.php#L550

This is, I suppose, so that we know which class to create a proxy for, but obviously it almost defeats the point of creating a Proxy in the first place.

Doctrine ORM doesn't have this issue I guess. Any thoughts?

[lsmith77]

well we can make it possible for the user to configure the class in the annotation optionally and then throw an exception on a mismatch.

[dbu]

Oh indeed, why not. Though not suitable for all cases, often you want a
mixed tree - or you can go with orm right away. Could we offer to set a
closure instead of a proxy? Sort of super-lazy?
Am 09.04.2015 17:05 schrieb "Lukas Kahwe Smith" [email protected]:

well we can make it possible for the user to configure the class in the
annotation optionally and then throw an exception on a mismatch.

—
Reply to this email directly or view it on GitHub
#628 (comment).

[sarcher]

I ran into this today while exploring performance around changing the fetch depth in my particular use case. Since the depth is a session-based setting, and the additional query happens within the scope of the original operation, it inherits the same depth setting. This actually can lead to a potentially very costly re-fetch of the same data. (For example, query with a depth of 3 on a node, and a companion query is issued for the parent that also has a depth of 3, getting most of the same object graph).

A workaround to that particular issue is to zero out and then restore the session fetch depth in PrefetchHelper::prefetchHierarchy() for Jackalope or any other depth-supporting session, which at least prevents this case, making the eager fetch only a single node and usually very fast. Of course, that requires a code change here, and I'm not sure that's one worth making if another solution is coming (although I would definitely consider this case a bug worth fixing, one way or another).

The ORM actually suffers from a similar problem with one-to-one relations on the non-owning side. The mapping knows there may or may not be an entity on the other side, and has no way of knowing whether or not to create a proxy without actually executing a query, at which point it of course has the object (or a null value). It's generally a bad way to map anything anyway, but happens often with legacy schema. The ORM workaround is to force a partial load of the entity with a query hint, knowingly leaving that association as a null value rather than a proxy. Such a hint might be a less invasive solution here, though.

[dbu]

good point about the prefetch helper. another thing could be when i ask for /parent/child to actually fetch /parent so that we have parent right away. this could get expensive however if there are many siblings to child. a query hint would tell phpcr-odm : i don't want the parent document to be populated, leave it at null? another idea: if the document itself would be a kind of a proxy, we could catch access to the parent field and initialize the parent proxy only at that point. we do know the parent path and we do know it must exist. the only thing we don't know is the class and hence we can't create the proxy of the parent without fetching data.