Task #4931
Check correct behaviour of object replacement in persistence
50%
Description
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):
- FLOW3_Persistence_Entity_UUID
FLOW3_Persistence_cleanProperties- FLOW3_Persistence_clone
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!
Updated by Karsten Dambekalns almost 11 years ago
- Status changed from New to Accepted
- Assignee set to Karsten Dambekalns
Updated by Robert Lemke almost 11 years ago
- % Done changed from 0 to 50
- Estimated time set to 8.00 h
Updated by Karsten Dambekalns almost 11 years ago
- Target version changed from 1.0 alpha 8 to 1.0 alpha 9
Updated by Karsten Dambekalns over 9 years ago
- Status changed from Accepted to Closed
- translation missing: en.field_remaining_hours set to 8.0