This was surprisingly easy to implement. Open question for me is if its matters when exactly we execute the move (right now its done after everything else) and if its ok to skip the move if the node is no longer registered.
initial support for DocumentManager::move()
added tests to check if remove/move do not get executed prematurely
do moves after removes
update path information after move
I think the behavior should match the behavior of the ORM: it you call persist() on an entity scheduled for removal in the UoW, it is removed from the scheduled deletions. the same should apply here: moving a node should cancel a previous deletion in the UoW, and deleting a node in the UoW should cancel its scheduled moves. This way, the second point in your comment is solved: there is no possible inconsistency as it cannot be moved an deleted at the same time
ok .. good point.
handle different order of persist()/remove()/detach()/move() operatio…
…ns by undoing previous operations
Merge branch 'master' into PHPCR-48_move_support
ok .. it seems we didn't handle this properly for deletes atm. so i fixed that and added support for this in move.
added tests for detach()
removed some unnecessary comments
so any @Parent @Child(ren) annotated fields do not get updated by the move operation, right? we should document that, could be confusing.
adding some doc for move operation #103
actually the @Parent can not go wrong as the moved document is still refreshed, and any other document does not change its parent, but the @Id field of children will be wrong too
yes .. i guess we could update the id's of children if they are connected to the parent by a mapping. for others it would be tricky .. however move operations are not common. so we could do the additional effort of updating id's when we do have move operations on all managed documents.
agreed. i just made that last comment for completeness if anybody looks at this pull request again. the doc says to call clear after the move, and thats good enough for me for now. tracking that stuff inside jackalope was enough of a pain, no need to re-start in the odm again...
i guess if we had observation .. we could hook in there ..