jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <mreut...@adobe.com>
Subject RE: workspaces & version storage
Date Wed, 05 Dec 2012 12:41:17 GMT

> From: Jukka Zitting [mailto:jukka.zitting@gmail.com] 
> On Wed, Dec 5, 2012 at 12:06 PM, Marcel Reutegger
> <mreutegg@adobe.com> wrote:
> > now, what does that mean for the current oak-core implementation?
> > to make version operations transactional we need the workspace
> > Tree and the version storage Tree under the same Root. this is trivial
> > if we just store the version storage under /jcr:system inside the
> > workspace. however that limits us to just one single workspace and
> > makes it IMO quite difficult to implement multi-workspace support
> > later. the only alternative that truly keeps the door open to support
> > multiple workspace is to decouple *at least* access to the version
> > storage from a client perspective. what I mean is, if we now say the
> > version storage is accessible (possibly also writeable) in an Oak workspace
> > at a specific location, then we have to stick to that layout forever unless
> > we break backward compatibility. therefore I think it would be good to
> > already now define that the version storage is a separate workspace,
> though
> > internally an initial implementation wouldn't actually have multiple
> > workspace but just expose the jcr:system tree in another workspace (as
> > a temporary solution). oak-jcr will then use that workspace to read
> versions.
> If/when we implement full JCR versioning (as opposed to simple
> versioning), the jcr:versionHistory and jcr:baseVersion properties of
> a versionable node need to be referenceable, i.e. calling getNode() on
> them should return the respective nt:versionHistory and nt:version
> nodes. I don't see a clean way of implementing this unless those nodes
> are (at least virtually) present in the same workspace.

good point. conceptually the UUID space of a workspace consists of the
UUIDs of the workspace plus the UUIDs of the version storage. this
means we'd have to extend the IdentifierManager in oak-jcr to consider
the logged in workspace as well as the version storage. A simple
implementation (as we have it in Jackrabbit) could simply check the
workspace IdentifierManager first and then fall back to the version
storage IdentifierManager. a more sophisticated implementation could
also include a BloomFilter (yay ;)).

would you consider this not clean?

and yes, I intend to implement full JCR versioning. simple versioning was
only introduced with JCR 2.0 and there's a lot of existing code out there
which depends on JCR 1.0, aka full versioning.

> > This has a number of implications. Validators, CommitHooks and friends
> > will see the entire repository, while they currently assume they only see a
> > default workspace. We'd have to change those implementations to take
> > the workspace name of the currently logged in session into account. This
> > actually extends to any code that operates on NodeStates or the
> NodeStore.
> That's actually why I've intentionally wanted to limit the amount of
> code that works with the NodeStore interface and rather just pass
> NodeStates around. For example all the CommitHooks or Validators
> operate just on NodeStates. And since the NodeState has no getParent()
> or getPath() methods, all that code should work exactly the same
> regardless of whether it is passed the entire repository or just a
> subtree. :-)
> > Most notably  this includes the QueryEngine and the QueryIndexProviders,
> > which are repository wide as well right now. An simple solution may be
> > to just wrap the NodeStore early with a WorkspaceNodeStore and only
> > expose the workspace NodeStates.
> These components also use just NodeStates nowadays, so no custom
> wrapping should be necessary.

right, that should work.

but what about plugins that would like to operate on the repository level?

e.g. the version commit hook I described would need to have access to
the workspace as well as to the version storage.


View raw message