You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have been relying on the behaviour of SomeEntityProxy::getId() not triggering n+1 queries (in the ORM), and recently with some refactoring I saw an endpoint go through the roof in terms of number of queries made.
Turns out it was due to a refactor of the following method on our entity
publicfunctiongetId()
{
return$this->id;
}
After doing some digging I found that any variations on this method prevent the proxy generator from adding the optimization to the proxy class for an entity
1
publicfunctiongetId()
{
// this is a commentreturn$this->id;
}
4
(this example doesn't even make it to the regex portion of the check, due to exceeding 4 lines)
publicfunctiongetId()
{
// this // is // a // long // commentreturn$this->id;
}
My documentation searching skills are likely poor, but this feature seems to be rather sparsely explained which may contribute to the difficulty in understanding the behaviour here.
It seems to me like the above examples should all be valid (and should allow getId() to skip proxy initialization)
I understand the need to prevent introduction of bugs through unexpected proxy behaviour
However I think my first 4 examples are much more likely to occur (and erroneously break the n+1 block) rather than the edge case presented in example 5.
There are a few options I see for resolving this (and I would be happy to contribute if there is consensus)
Better documentation on this functionality and caveats (assuming my failure to find any is valid)
Loosen the restrictions on "cheap check" to allow for comments
Modify (or abandon) the regex and strip the code of comments before applying the regex. A couple of options for modification off the top of my head:
Allow for type casting and primitive concatenation (complex to build a regex for this?)
Simpler: Look for occurrences of other mapped properties in the method body, i.e. $this->xxx where xxx != <identifier>, if there is a match then return false from isShortIdentifierGetter
The text was updated successfully, but these errors were encountered:
anything doing more than returning the id property directly means that the real method must be called, and so that the proxy must be initialized (the id property is still null for non-loaded proxies).
As I figured out the $class->getIdentifier() array for the embeded Entity would have id.value item.
And identifier in this case would still be id, so the $cheapCheck would be false.
We have been relying on the behaviour of
SomeEntityProxy::getId()
not triggering n+1 queries (in the ORM), and recently with some refactoring I saw an endpoint go through the roof in terms of number of queries made.Turns out it was due to a refactor of the following method on our entity
After doing some digging I found that any variations on this method prevent the proxy generator from adding the optimization to the proxy class for an entity
1
2
3
4
(this example doesn't even make it to the regex portion of the check, due to exceeding 4 lines)
My documentation searching skills are likely poor, but this feature seems to be rather sparsely explained which may contribute to the difficulty in understanding the behaviour here.
It seems to me like the above examples should all be valid (and should allow
getId()
to skip proxy initialization)I understand the need to prevent introduction of bugs through unexpected proxy behaviour
5
However I think my first 4 examples are much more likely to occur (and erroneously break the n+1 block) rather than the edge case presented in example 5.
There are a few options I see for resolving this (and I would be happy to contribute if there is consensus)
$this->xxx
wherexxx != <identifier>
, if there is a match then return false fromisShortIdentifierGetter
The text was updated successfully, but these errors were encountered: