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 13:47:41 GMT

> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> There's the conceptual mismatch with the potential breakage of statements
> like:
> node.getSession().getNode(node.getProperty("nt:baseVersion").getNode()
> .getPath())
>    node.getVersionHistory().getSession().getNode(node.getPath())

that must definitively work. I'm pretty sure there is code like this out there...

> I'm not sure if we'd in practice encounter problems like this, but it
> does seem potentially troublesome if content accessed through one
> session/workspace would actually be associated with another
> session/workspace.

hmm, good point. I didn't think about this yet. I don't particularly see a problem
with the JCR Session. There should still be just a single JCR session instance in
oak-jcr. but when accessing the Oak API, it would require two ContentSessions.
This could indeed be problematic, because there's no guarantee that both
sessions are on the same revision...

we could introduce a method that allows you to get a Root for another workspace
based on an existing Root. This could also come in handy when we want to
implement cross workspace operations. In Jackrabbit we have that functionality
in WorkspaceManager.createSession() and in CRX in CRXSession.getSession().

> > but what about plugins that would like to operate on the repository level?
> One option would be to have a separate category for such plugins that
> disables the subtree restriction for such cases. Or we could
> alternatively make all plugins operate on the full repository and
> simply have some of them explicitly step down to the appropriate
> subtree before further processing, which should be a simple and safe
> enough code change.



View raw message