Reorder with rename test #277
Conversation
|
i think renames are only put into phpcr on flush. so the var_dumps can be expected to return the old name. but i fear the reordering is taking shortcuts with phpcr to decide how to order things. what the right thing is depends on the order in which the UoW is telling phpcr about the move and the orderBefore. semantically i would expect the dm to handle that case properly. so depending on the execution order it either needs to update pending reorders when a move is detected maybe? |
|
i just investigated this a bit. from the way the children collection works, it is clear what happens. we ask phpcr for the list of children, but the rename is not put into the phpcr layer before the flush. if we want this to work, we would need to build a pending move table in the unit of work where explicit moves and move by assignment are tracked, and adjust the children mapping to be aware of that. even then, if you first would load the parent and then move the child, the children collection would still not see the move. i am afraid of the complexity we run into with such things. we have to figure out what the sane use cases are and stick to those. |
| $this->dm->clear(); | ||
|
|
||
| $parent = $this->dm->find(null, '/functional/source'); | ||
| $this->assertSame(array('second', 'first', 'third', 'fourth'), $this->getChildrenNames($parent->getChildren())); |
There was a problem hiding this comment.
i would expect the array to be 'second', 'renamed', 'third', 'forth' - that was the point of renaming... however, we get 'renamed' first as the reorder does not work, the child will still have the old name 'first' at the point when reorder is calculated.
This is a failing test, is it valid behavior?