PHPCR-ODM implementation?

[dantleech]

I recently (well, months ago) made a big PR on the phpcr-odm UOW to switch it over to using an operation queue:

doctrine/phpcr-odm#396

The problem was that in an ODM you have the concept of moving nodes, and when you are moving nodes order becomes important. e.g. you move node-a to node-b then create a new node-a in the same transaction, it is then necessary to perform the node-a move before creating the new node-a. The current PHPCR-ODM logic doesn't do this, and breaks.

Can you offer any advice on solving this problem - would this be possible with this library? Do you think an operations queue is a good idea? /cc @dbu @lsmith77

Cheers!

[Ocramius]

@dantleech the idea of ChangeSet is to be persistence agnostic.

The UnitOfWork will just provide a list of changes to a "committer" object (which in this case may be PHPCR ODM specific) - that committer will then handle sorting of the operations to be executed.

In pseudo-code, it will be like following (some tests already verify this behavior):

$committer = new CSVFileCommitter('path/to/file.csv');
$uow->commit($committer);

var_dump(file_get_contents('path/to/file.csv'))); // output all what was saved

This also enables manual rollbacks if needed (for storage layers that don't support transactions, for example)

[Ocramius]

Yes, I also basically told you "your problem" :D

[dantleech]

I am wondering if the users commit order is ultimately important or not, jf it is then I guess it should be recorded by the UOW and then passed to the Comitter, or, if the comitter is capable of taking an unordered heap of operations (e.g. scheduledInserts, updates, removals, moves) and always determining the correct sequence of operations. and then -- is there an advantage in either approach?

Hmm.

[lsmith77]

I think commit order can be useful indeed. For example MySQL FKs require that referential integrity be maintained after every query, even inside a transaction.

[Ocramius]

@lsmith77 the UoW should keep the order unchanged (as given by the user) and pass it to the committer as-is. The committer should then decide what to do with it, since it may have better understanding of the storage.