Versioning confusion

[kevin.thorley]

I am trying to create versioned nodes using ModeShape.  I have a few classes that I wrote against JackRabbit, and have modified the setup to use a Repository retrieved from ModeShape, but otherwise have left all other code the same.  My code for creating a new, versionable node is as follows:

newNode = parentNode.addNode(name, "nt:file");

newNode.addMixin("mix:versionable");
System.out.println("versionable: " + newNode.isNodeType("mix:versionable"));
this.session.save();
newNode.checkin();

This was based on sample code from the JackRabbit project.  However, running this code within ModeShape results in the following:

versionable: true
Exception in thread "main" javax.jcr.UnsupportedRepositoryOperationException: This operation requires that the node be versionable (that is, isNodeType("mix:versionable") == true)
    at org.modeshape.jcr.AbstractJcrNode.checkVersionable(AbstractJcrNode.java:1416)

Note that the sysout is confirming that mix:versionable is set on the node.

In a debugger I saw the following when I inspected the newNode object:

Before saving session:

/config/t/t1000/config.xml {jcr:primaryType=nt:file, jcr:mixinTypes=[mix:versionable], jcr:uuid=3d31f489-5a74-4974-bf10-9e8aa03b24f3, jcr:created=2010-05-06T13:13:43.306-04:00, }

After saving session:

/config/t/t1000/config.xml {jcr:primaryType=nt:file, jcr:created=2010-05-06T13:14:08.227-04:00, }

So, after saving the session, the mixin type disappears (along with the jcr:uuid).  Is this the intended behavior?  Should I be checking in before saving?  Does ModeShape implement the versionin differently than JackRabbit, therefore requiring a change in the order of operations (save, checkin)?

Thanks,

Kevin

[bcarothers]

What kind of repository are you using?  The FileSystemRepository and SvnRepository don't have the ability (out of the box) to store arbitrary properties like jcr:mixinTypes, so they drop those properties silently at save time.

[kevin.thorley]

I am using the svn repository.  When you say "out of the box", do you mean there is additional configuration that can be done to enable this?  Or there needs to be more work done in code to support it?

Thanks,

Kevin

[bcarothers]

Both.

To add some context, neither the file system connector nor the SVN connector was intended to store arbitrary JCR data.  They were really meant to expose existing content on your network as JCR (or expose certain kinds of content to external systems on the network).  In a lot of cases, that would be enough.  If you needed to do more (e.g., version the data), you could always copy that content into another part of a federated source that mapped to a different underlying connector.

The FileSystemConnector was actually expanded to allow storage of arbitrary properties through the CustomPropertiesFactory.  It takes a little bit of code and configuration to set it up, but it's not particularly hard.  The SvnConnector doesn't support CustomPropertiesFactory yet, but it could be made to do so.

I think there's a bit of a disconnect at times for people coming from a JR background.  In JR, the file-backed repository is a very common repository for storing arbitrary data on a local file system.  In MS, the FileSystemRepository is a bridge to the file system that only stores nt:files and nt:folders by default (with no mixins allowed).  IMHO, the closest MS equivalent to the JR file repository is an Infinispan repository with a write-through cache.

The simplest alternative to set up though at the moment is a JpaConnector using the SimpleModel.  That will durably store any kind of JCR content in almost any database supported by Hibernate.

[kevin.thorley]

Maybe I should give a brief overview of what I'm trying to accomplish.  We have a rather large svn repo holding config data (a mix of .xml and .property files).  For several reasons we would like to move away from the current model, especially in terms of requiring all clients of this data to have a local svn view.  My first look was at JR, migrating our file-based svn system to a node-based JCR system backed by a MySql database.  Now I am looking at ModeShape for comparison.  The advantage of ModeShape is that we could connect to our existing svn repository and skip the data migration step.  However, we will still need access to the versioning capabilities of subversion.  If this is not supported via mixins in MS, is there another way to access previous versions of a document (Node)?  Or is only the head of the repository accessible?

Thanks,

Kevin

[bcarothers]

Thanks for the additional context!  Let me start with the pros and cons of the SVN connector...

The only way to persist a content change to an SVN repository is, of course, to commit it - so JCR saves() end up corresponding to SVN commits.  We've kicked around the idea of mapping JCR checkins to SVN versions, but that gets a wee bit complex, since JCR mandates its own storage structure for versions.

Are you looking to be able to view the SVN history of a node from within the repository, or are you just trying to preserve a known-good way to rollback to a previous version?