Flush could delete entities before inserting new ones

[MacDada]

I have a unique (not PK) column. I need to remove old entities first and then add new ones (replacements).

Yeah, I've seen this: #5368

But I've also seen a "could be done" solution:

A function "setShouldPerformDeletesFirst" as described in http://docs.oracle.com/cd/B31017_01/web.1013/b28218/uowadv.htm#i1137484 would be very useful in those cases.

What I propose, is that this gets implemented. From the dev point of view, it would be cool, if one could do that like this:

* @ORM\OneToMany(targetEntity="Whatever", mappedBy="Me", cascade={"persist"}, orphanRemoval=true, removeBeforeAdd=true)

[ureimers]

I'm not quite sure if removeBeforeAdd should only be available on relations. You could easily think of a case where you replace entity A with B with both having the same uniquely constrained fields.

[fsmeier]

+1 here

[johandouma]

+1.
This issue seems related to #6776, in case other people are searching. And #2310, #7721, #5109 (this last one has a few comments with lots of upvotes too) - this really is a larger issue that IMO should be attended to, a removeBeforeAdd option may only be a bandaid

[SmasherHell]

+1 That is quite a challenge to respect OCP when doctrine removes "merge". There is no way to update an object from a clone within a transaction. How to have a separation of concerns between logic and persistance when we must flush a state in the middle of logic

[hhamon]

I faced this issue as well on my client project. We had to remove the SQL unique constraint on the table to ensure the Doctrine SQL transaction can be complete. But ideally we would need both the SQL unique constraint (to always ensure consistency in the database) and in the SQL transaction when Doctrine flush statement is performed.

[mpdude]

@SmasherHell I am not sure if it would support your use case – probably it may be difficult to deal with two entities at the same time that share the same primary key value, and to have one replace the other in a single transaction.

The OP request is more about being able to meet other (non-primary key) constraints.

[mpdude]

#10809 adds an example that shows why we cannot – at least not, in general – change the current order of operations in the UoW.

[maddanio]

may I ask why the order is not simply preserved? that would likely be the expectation of the library user. doctrine reordering actions is susprising.

[mpdude]

No, that’s the promise given by the ORM: You tell it which entities you want to have tracked, and when you call flush(), it executes the (minimum amount of) queries it takes to persist changes.

That includes giving the ORM some freedom to order operations as it sees fit.

Additional unique constraints in the database as we‘re discussing here may interfere with that. They prevent the ORM from doing things in the planned order, through restrictions it cannot foresee and/or efficiently include in the commit order computation.

[maddanio]

can you give an example where not keeping the order is neccessary to fulfil that promise?

[greg0ire]

@maddanio you can read up on this at #10547

[maddanio]

hmm, but i don't quite see how this completely prevents keeping ordering. yes in some situations things need to be reordered, but if one really only does the required reorderings and keeps things otherwise stable I think most of the problems would go away, or am I overlookling something?

[mpdude]

but if one really only does the required reorderings and keeps things otherwise stable I think most of the problems would go away

I think that is how it is implemented. If you have a reproducible case that indicates otherwise, I’d be happy to look into it as a potential bug

[maddanio]

Ah ok, well need to find out how to reduce this. But basically i am removing an entity and then adding another one with the same primary id. Adding a flush between makes it work. Hmm, but maybe we are using a too old doctrine version. Will check

[mpdude]

You’re even describing a special case where the unique constraint is for the primary key, not just for any other column.

You must be using application-provided IDs, otherwise this kind of ID reuse would not happen.

This is not going to work for at least one reason apart from the order of operations during flush: Since the identity map refers to entities (object instances) by means of the ID, there will be a collision already when you try to add the one object and have the other one set up for removal.

[maddanio]

Is there then a stable way to completely replace an object?