phpcr-odm
phpcr-odm copied to clipboard
doctrine
RFC: Enforce UUIDs on mutable documents
What
As per discussion with @dantleech, the current UnitOfWork identity map is very messy, and unlikely to be compatible with the upcoming Ocramius/ChangeSet rework.
Why
There are also some cases where identifier changes in the current strategy cause problems, such as:
- loading an object
/foo/bar - moving it to
/foo/baz - adding a new object
/foo/bar - flushing
As well as other conditions where race conditions in a single flush may happen.
Solution
Therefore, I suggest that the ODM enforces UUID mixins on nodes:
- documents and node types registered by the ODM always have a UUID mixin
- UUID is not required to be hydrated into the object
- documents and node types NOT registered by the ODM are not required to have an UUID mixin, but may not be modified (read-only is enforced, and changing the documents causes exceptions on
flush())
A big and fat :+1: there is a PR waiting for using proxies with uuids, which should be much easier after that. Cause, please correct me, we would reference each document by uuid then. =
Right. I'd still suggest allowing UUIDs to be skipped, but in those cases, write operations should be denied.
Even though it's kind of a pity to always have them, they make things incredibly easier.
But would have one Question: How to handle all "normal request" by path? I think nearly 95% calls auf find() and findMany() are using the path as parameter. So you would need fast mapping to find a scheduled/mapped document by its path to. Maybe an UoW::getDocumentBy($bla) where bla can be both.
+1. Although I should point out the example you gave above is not caused by the identity mapping (at least it is not the principle cause)
The problem is that the UOW calculates the changeset but does not preserve the order of operations.: If you delete a node then move a node to the path of the deleted node, the UOW will always execute move first and delete second (hmm, or vice-versa..)
But yeah, having the UUID always mapped would simplify things alot and be a very positive step forward.
We can expand the existing phpcr:managed mixin node type to "include" the uuid mixin I think.
:+1:
about operations order vs changeset calculation: this is a fundamental question, but basically we can say that the changeset calculation is flawed. it should detect that something moved somewhere, and do a move on phpcr, and then add something new, rather than trying to mix up documents. with the uuid this should become more obvious as we won't confuse things that swapped paths anymore. the phpcr implementation could do an operations list (as does jackalope now)
I'm not sure what this will mean for existing projects with respect to migrating existing content, can you add the mixin to existing nodes and generates it an uuid then? What about adding a custom property to phpcr:managed that is controlled by the ODM and would allow for an easier migration regardless what the phpcr backend supports?
yes, you can add the mix:referenceable to existing nodes. the repository impl will automatically add a uuid at that point. not sure if the phpcr-shell by @dantleech can set a mixin by query (or only properties) - but sure, we will need to provide an upgrade path.
btw, imo this is a doctrine phpcr-odm 2.0 topic, not something we will do in a minor change.