Fetching untracked entities

[dbu]

In #7901, detaching entities has been deprecated. There are use cases where having untracked "entities" would be very useful though. In our case, we have a system that reads various entities and then creates or updates an entity (of a different type). We know that the entities we read will not (or even must not) be changed. And we would be glad to be able to leave those objects up for garbage collection. @stof mentions a similar issue in the discussion on the deprecation merge request.

I can see that the general detach is very fragile and can lead to weird issues. But we know we don't want to entity to be tracked when we fetch it from a repository/entity manager. Could we make a query hint that does dehydrate to the object but not add it to the identity map? Plus a way to find() without tracking (probably a separate method - find does not take query hints)?

@thePanz and me would have some time to work on this if we can agree on the need for this and an architecture for it.

[dbrumann]

Just out of curiosity, do you think modifying the change tracking policy for the entities would help in your use case or would this still be problematic because these entities will likely not be picked up by garbage collection?

[dbu]

our main concern is indeed garbage collection, as we process a lot of data to create a new entry. i am not too familiar with the change tracking policy, but from the name of it assume i could tell to not track changes on some entity. that seems not to match our use case, and i could probably clone the entity to get the same effect? (except maybe for relations that are loaded as proxy only at the time of cloning)

[stof]

my own use case for that is a case where I deal with my entities in a read-only way for a processing, but dealing with a big number of such entities (using Query::iterate() of course, not getResults).
The change tracking is not the issue in my case. The issue is the fact that the identity map retains the object.

Today, I deal with that with detach(), which is deprecated. I understand that detaching arbitrary objects from the identity map will cause issues for the change tracking of related objects (hence the deprecation). But if we can hydrate objects without putting them in the identity map (and so also untracked for changes), we won't affect the change tracking of other objects, as these objects won't ever enter the identity map before being removed from it.

I think that to be safe, we might need to reuse existing entries of the identity map if the fetching involves some objects which are already fetched (especially regarding toOne relations). but newly fetched objects should be hydrated without entering the UnitOfWork after that.

[beberlei]

Detach might be undeprecated

[stof]

Undeprecating it would be fine with me. Maybe documenting it as an advanced topic.