Implement versioning support

[benglass]

Assigned to @danrot

This is not currently supported by the dbal client

https://github.com/jackalope/jackalope-doctrine-dbal/blob/master/src/Jackalope/Transport/DoctrineDBAL/Client.php#L69

There are 2 kinds of versioning: versioning (with branching/tagging) and simple versioning (linear only).
We would start with simple only.

jackalope-jackrabbit supports linear versioning with taggin but no branching (need confirmation this is accurate) so that would be what we'd shoot for.

Implementation notes

• The Client would need to implement VersioningInterface[1]
• The VersionManager[2] does most of the logical side

So the Client should handle the communication, like setting the correct properties.

Tasks

• apply the mix:versionable mixin to a node
• create a new version of a node
• get the data from an old version of the node
• write protection for not checked out nodes
• restore an old version of a node
• delete a version (optional feature)

[1] https://github.com/jackalope/jackalope/blob/master/src/Jackalope/Transport/VersioningInterface.php
[2] https://github.com/jackalope/jackalope/blob/master/src/Jackalope/Version/VersionManager.php

[dantleech]

That is correct. Versioning is a pretty specialized domain I think. We could either do something really "dumb" and store a complete copy of each node every time it is modified. Or do something nicer by only recording the differences and playing them back / rewinding them.

Dumb versioning would cause a pretty severe storage overhead in an enterprise context (but then people wouldn't generally be using doctrine-dbal in an enterprise context).

i think maybe having a pluggable system would be the best option. I.e. we can implement a dumb driver to start with and then implement a more sophisticated one later.

[benglass]

Agreed @dantleech that we could provider different adapters and start with a dumb one that just records to a shadow table on each update. Can you confirm that branching is not supported in jackrabbit but tagging is and that would be a good target?

[dantleech]

Well, jackrabbit is the reference implementation, so it supports branching and everything. Its the jackalope-jackrabbit layer which does not support branching (should be easy to implement as it is just a case of sending the correct requests to the jackrabbit server).

But yeah, the jackalope-jackrabbit layer supports "simple versioning". Not sure about tagging.

/cc @wjzijderveld @dbu @lsmith77

[wjzijderveld]

I don't know details about tagging in jackalope-jackrabbit.

I do know that Versioning in jackalope-doctrine-dbal has been on my long-term todo-list since 6 months. But long-term means: when I have nothing else to do.... so that won't happen any time soon I'm afraid :)

Also see: https://groups.google.com/forum/#!topic/symfony-cmf-devs/uPqAwKdNxCg Yeah, ignore that.. That was your own post :)

[dantleech]

Btw, you can play with the current versioning stuff with phpcr-shell:

version
  version:checkin                  Checkin (commit) a node version
  version:checkout                 Checkout a node version and enable changes to be made
  version:checkpoint               Checkin and then checkout a node
  version:history                  Show version history of node at given absolute path
  version:remove                   Remove a node version
  version:restore                  Restore a node version

[dbu]

if i am not severly mistaken, we did implement tagging a version in jackalope-jackrabbit. best have a look at the tests in phpcr-api-tests - if we implemented something, there will be tests for it.

[dbu]

i would honestly rather invest in improving the jackalope-jackrabbit implementation than in re-building that in doctrine-dbal. it will be a lot of effort but remain inferior and more bug risk than jackalope-jackrabbit. in an "enterprise" context, tomcat and jackrabbit should not be an issue and provides better performance.
that said, i certainly will review pull requests on doctrine-dbal for versioning and if it works correctly, we can merge it in. the naive approach at least should not even be that hard.

[benglass]

@dbu understood but in our case we would like to add simple versioning to our cms and don't want to REQUIRE the installation of jackrabbit so I think doing to simple versioning with tagging via a shadow table would be a nice option. To me it also seems like it would be a good selling point to introductory users that it supports versioning without an added requirement of jackrabbit.

[lsmith77]

yeah .. I think its important to support this also for doctrine dbal as even if you do not have large scalability needs you might need versioning. simple versioning should indeed not be so hard to implement.

[dbu]

@danrot is working on this

[danrot]

I've been working on the checkin and checkout function on jackalope/jackalope#285 and #272, which will hopefully be merged quite soon. These PRs basically do some bootstrapping, sets the versioning properties on the node and creates the versions in the jcr:system-node.

In #282 and jackalope/jackalope#286 a frozen node will be created.

There are still some failing tests I have to look deeper at, and then the last thing missing is the restore functionality.

[danrot]

@dbu just merged my PRs, which included support for saving the history. This issue now has a bullet list of what is done and what remains to do.

I am not sure if deleting a version is absolutely required, since even the specification somehow says that it is optional ("In some implementations it may be possible to remove versions..." in section 15.8 on http://www.day.com/specs/jcr/2.0/15_Versioning.html). So I could imagine to get this functionality merged without the functionality to remove a version.

I am going to work on restoring an old version next.

[dbu]

cool. yeah i think restoring and the check on a node whether it is writeable seem the only must-have parts.