phpcr-odm
phpcr-odm copied to clipboard
Preserve order of operations
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.
@dbu any idea why this is not working on Jackrabbit? Something on our end?
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.
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?