Future fix Finder::hydrateFromGrouped does not preserve empty relationship results for existing entities, which can resulting in redundant queries

X

Xon

Well-known member
Affected version
2.0.12
If the first poster of a thread has no session activity, a redundant query will be done when checking isOnline() for that post.

This is because the user entity is created in the thread query, which does not query for session activity. The post query does, but because the user entity is already loaded, it just grabs that. This user entity does not have a Activity relationship entry in it's relations array.

hydrateFromGrouped does not appear to populate the _relations field for an existing entry, even if relations are loaded. This works because instantiateEntity will record a positive lookup. However instantiateEntity does not populate entities with nulls, this results in an extra query when that known-empty relationship is later accessed.

(snapshot of loading a Post, which has a user loaded by a Thread)
190784

Generic reproduce steps;
  1. Load a entity in query 1 with no relationships selected.
  2. Load that entity again in another query with relationships that are null.
  3. Access the relationships which should null values
  4. Observe extra unexpected queries
 
Last edited:
Conceptually, this is a known issue and there is actually a comment about it in the entity manager when instantiating from a cached entity. In most cases, it doesn't really have a major effect. Provided the relationship happens based on a primary key, accessing the relation will check the entity cache first and find it there. So this can also happen with some non-primary key joins (even when the match has been successful). Generally, I haven't seen it come up particularly often (and the resulting query would generally be well indexed).

There is scope to change this, but we have to be careful, as it would be possible to populate a relation based on values in the DB that don't match the state of the entity internally (due to changes that have been made). We may consider changes in the future here.
 
Top Bottom