Deprecate EntityManager::flush with $entity argument

[beberlei]

The method EntityManager::flush has an optional argument $entity (either accepting a single entity or array of entities) that when passed are the only set of entities considered in compute changeset operation. The idea originally was to allow more performant flush operations when a lot of entities are in the identity map.

However due to restrictions in how the UnitOfWork operates, it had to also "flush" other entities sometimes that were not passed to flush, making the operation inconsistent.

As such we decided to deprecate this approach to flushing and only allow a full flush for now.

Alternative: If you want to keep the set of entities small that flush operates on, you could decide to use the explicit change tracking policy for an entity instead of the implicit one. https://www.doctrine-project.org/projects/doctrine-orm/en/2.8/reference/change-tracking-policies.html

[miedzikd]

Hello @beberlei :)

Can you give me another tip, how can I solve my issue when flushing objects as parameters, will it be deprecated?

I have one huge table with Orders. It's used in a lot of places in the system.

Normally we use ->flush() without passing Order object as a parameter, but I have one command job that regenerates all Orders. Im doing that in batch for 1000 orders per execution.

If I pass Order object to flush - whole execution take more or less 60s. Without that 1200s, because size of unitOfWork is too huge.

Explicit change tracking policy can be apply on whole entity level only? I can't change this because it is used in too many places. Can I apply the policy only in one action? or one command?

Greetings from Poland :)

[wadjeroudi]

@beberlei @Ocramius any news on this deprecation ? We should be able to do a specific data change at least in a new transaction without flushing the whole changes.
Maybe some sort of temporary clear() on entityManager and restore the unit of work after :

$em->saveStateAndClear() // temporary reset
$em->persist($entity)
$em->flush() // do not auto restore state in case multiple flushes are needed
$em->restorePreviousState()

I'm probably wrong but adding a property on EntityManager $savedUnitOfWork to store the current uof, instantiate a new empty one seems pretty simple imho :

$this->unitOfWork        = new UnitOfWork($this);

[poolerMF]

@beberlei @Ocramius any news on this deprecation ? We should be able to do a specific data change at least in a new transaction without flushing the whole changes. Maybe some sort of temporary clear() on entityManager and restore the unit of work after :

$em->saveStateAndClear() // temporary reset
$em->persist($entity)
$em->flush() // do not auto restore state in case multiple flushes are needed
$em->restorePreviousState()

I'm probably wrong but adding a property on EntityManager $savedUnitOfWork to store the current uof, instantiate a new empty one seems pretty simple imho :

$this->unitOfWork        = new UnitOfWork($this);

+1

[Fedik]

We should be able to do a specific data change at least in a new transaction without flushing the whole changes.

It already possible, if I right understood the linked doc.
We have to define DEFERRED_EXPLICIT for ChangeTrackingPolicy.
Then flush() operation will take in count only an entities that was explicitly marked to "persist" with $em->persist($entity).

Old:

$em->persist($entity);
$em->flush($entity);

New:
Set mapping to DEFERRED_EXPLICIT, and:

$em->persist($entity);
$em->flush();

[GDXbsv]

@Fedik I see a problem with it:
If you not set DEFERRED_EXPLICIT as default and only one possible value for all entities, then if some other entity was changed in a different place without DEFERRED_EXPLICIT then this entity will be saved as well. So we still can not prevent flushing unexpected entities.

[Fedik]

That correct, and that why you have to be sure all your Entities is set to DEFERRED_EXPLICIT(or NOTIFY) and that you call $em->persist($entity) when changes need to be written.
Unless your App requires different. I think.

[aniolekx]

Is it possible to set ChangeTrackingPolicy per script execution? I am happy enough that whole app is set to Deferred Implicit, but for data upload from excel files I need Deferred Explicit, removing of that option will add me a lot of work (I will have to check whole app where we have missing persist)

[derrabus]

Fixed via #9485.

[kgasienica]

There were any discussion about that? This change makes many scripts in batches last way much longer. And what is even worse, since this change you can no longer be sure which things are flushed.

If I have to be honest, I don't really like this change.