jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: workspaces & version storage
Date Wed, 05 Dec 2012 11:29:57 GMT

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.

> 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.


Jukka Zitting

View raw message