Check correct behaviour of object replacement in persistence
When an object that is a persisted entity is cloned, we (through AOP) set a cloned flag
and drop the memorized clean state of the object. Why is that flag still true after calling Repository->update() was the original question. It turns out we need to check the correct behaviour of the persistence in (at least) the following cases:
- cloned object is given to update(), then to add()
- cloned object is given to add(), then update()
- cloned object is given to replace(), what about doing this multiple times?
- the cloned object is given to update() and/or replace(), now the original is in turn added again
Part of the problem is to find out which of those scenarious should be allowed and what the correct behavior would be...
The involved data that is involved with this is (at least):
Along the way we probably need to make sure the memorized clean properties are not thrown away when cloning, because after an update() (or replace()) call we need those properties for correct persistence (and because of my planned solution for #4317).
Also make sure entities given to replace() get the new UUID also in their internals!