Task #4931

Check correct behaviour of object replacement in persistence

Added by Karsten Dambekalns about 12 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Must have
Category:
Persistence
Target version:
-
Start date:
2010-03-08
Due date:
% Done:

50%

Estimated time:
8.00 h
Sprint:
PHP Version:
Has patch:
Complexity:

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!

Also available in: Atom PDF