Skip to content

initial support for DocumentManager::move() #103

Merged
merged 8 commits into from Feb 9, 2012

3 participants

@lsmith77
Doctrine member
lsmith77 commented Feb 9, 2012

see http://www.doctrine-project.org/jira/browse/PHPCR-48

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.

@stof
Doctrine member
stof commented Feb 9, 2012

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

@lsmith77
Doctrine member
lsmith77 commented Feb 9, 2012

ok .. good point.

@lsmith77
Doctrine member
lsmith77 commented Feb 9, 2012

ok .. it seems we didn't handle this properly for deletes atm. so i fixed that and added support for this in move.

@lsmith77 lsmith77 merged commit d2fbfdb into master Feb 9, 2012
@dbu
Doctrine member
dbu commented Feb 13, 2012

so any @Parent @Child(ren) annotated fields do not get updated by the move operation, right? we should document that, could be confusing.

@lsmith77
Doctrine member

correct.

@dbu dbu added a commit that referenced this pull request Feb 13, 2012
@dbu dbu adding some doc for move operation #103 9556fc7
@dbu
Doctrine member
dbu commented Feb 13, 2012

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

@lsmith77
Doctrine member

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.

@dbu
Doctrine member
dbu commented Feb 13, 2012

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...

@lsmith77
Doctrine member

i guess if we had observation .. we could hook in there ..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.