Preserve order of operations

[dantleech]

This PR is aiming to preserve the order of operations, it tries to do this whilst preserving the current behavior as much as possible.

• Everytime an INSERT, MOVE or DELETE is made, we add an Operation to the TreeOperationQueue
• No such action is taken for REORDER or UPDATE

When flush is called:

• The execute* methods are called with batches of operations, e.g. INSERT, INSERT, INSERT would be a single batch, however INSERT, INSERT, MOVE, INSERT would be three batches, so that the move is executed after the first 2 inserts.

[dantleech]

Not 100% sure about the validity of this. If the Document was previously removed, and then re-inserted we remove all REMOVE operations from the stack. Not sure if that could conflict somehow with MOVE or REMOVE.

[dbu]

if you want to record operations, i think you would need to queue another add operation instead. i am sure it would be possible to find some hairbrained scenario where this makes a difference. and probably some very real usecase with listeners doing many things could actually result in the same scenario and actually make sense...

[dantleech]

@dbu any idea why this is not working on Jackrabbit? Something on our end?

[dantleech]

CREATE /functional/user1
CREATE /functional/user2
CREATE /functional/user2/subuser
MOVE /functional/user2/subuser /functional/user1/subuser
REMOVE /functional/user2
FLUSH

Jackalope-jackrabbit sends the following POST:

--0935d494bb0a33542b1ed402934cca2a
--0935d494bb0a33542b1ed402934cca2a
--0935d494bb0a33542b1ed402934cca2a
Content-Disposition: form-data; name=":diff"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

-/functional/user2 : buser : /functional/user1/subuserstructured","jcr:mixinTypes":["phpcr:managed"],"phpcr:class":"Doctrine\\Tests\\ODM\\PHPCR\\Functional\\User2","username":"test",}
--0935d494bb0a33542b1ed402934cca2a--

Resulting in:

PHPCR\PathNotFoundException: HTTP 409: /functional/user1/subuser

If I catch the PathNotFoundException the specific INSERT, MOVE, DELETE test works as expected.

[dbu]

this is a behaviour change i think, if we previously auto-persisted documents upon move operations.

[dbu]

interesting! about the jackrabbit issue: can you try to do that in a phpcr-api-test (CombinedOperationsTest i guess) to see if we have a bug there?

i think there is a philosophical question we need to decide. as i understood, doctrine calculates the optimal path to transform an object model into database operations, and does not record changes procedurally. but if we don't manage to calculate this transition, maybe explicit ordered operations make more sense?

@Ocramius @lsmith77 what do you think about this?