Description
Feature Request
Q | A |
---|---|
New Feature | no |
RFC | no |
BC Break | no |
Summary
I am maintaining a Doctrine-based ActiveRecord implementation (yes, I know that's probably considered an antipattern, but there's a ton of code built on that, so what are you going to do?). One of the features I need to provide is that you can have two different copies of an entity, i.e.:
$object1 = new my_class($db_id);
$old_value = $object1->property;
$object1->property = 'some value';
$object2 = new my_class($db_id);
if ($object2->property == $old_value) {
echo "GOOD";
}
$object1->save(); // 'some value' is now saved in the DB
$object2->save(); // $old_value is now saved in the DB, 'some value' was overwritten
The way I implement that is by detach
ing the entity once a property changes, and when save
gets called, I merge
it back in (there's a bunch of other things going on, too, but that is the gist of it).
With orm 3.0, that won't work any longer, because merge
is scheduled to be removed (even though detach
apparently stays). So I was wondering: How big of a burden would it be to continue supporting merge
? Because as far as I can tell, my only alternative would be to clear
the entire EntityManager, then load the entity again from the DB, copy over the properties from the detached copy and then calling persist
/flush
, which ofc totally kills performance. Which reminds me: flush($entity)
is also deprecated. So I guess undeprecating that would be part of my feature request, too :-)
If you say it's impossible to support these features, I understand. But I thought it can't hurt to at least ask. Also, if someone has an idea how else I might implement the behaviour I need, I would be very interested to hear that!