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: Oak & JCR versioning
Date Tue, 04 Dec 2012 14:41:35 GMT

On Tue, Dec 4, 2012 at 2:02 PM, Marcel Reutegger <mreutegg@adobe.com> wrote:
> this implies that oak-jcr supports non-trivial node type modification. do
> we really want to go there? to me this sounds like opening pandorra's
> box :-/

No, oak-jcr doesn't need to support any such things. But it would be
nice if the system allowed someone to implement something like that
without having to tweak the internals.

> I don't think this would require changes to the core implementation.
> it would just be one more hook watching jcr:baseVersion. similar to
> a restore the hook could allow modifications to jcr:baseVersion when
> it is checked out and then perform the rebase.

Yes, one could do that, but only if when you can adjust the set of
hooks deployed with the repository. I'm hoping for a solution where a
client that sees nothing but the external API would have as much
freedom as possible within the bounds of access control and repository

> you mean checkin a node, which has two modified properties, but we
> only want to check in the change to one of the properties? hmm, no
> that wouldn't be possible easily. but with JCR that's not possible either
> and as the subject indicates, this is about JCR versioning ;)

Right, but why limit our options, or more importantly the options of
people who might want to extend Oak beyond JCR?

> the major benefit I see with a commit hook based approach is
> that we can seal off the version store and make it read-only. I think this
> simplifies the process of mounting the version store into the workspace.

I see the point, but I don't think you can make the version store
read-only with this approach. How for example would you trigger
operations like VersionHistory.addVersionLabel() or


Jukka Zitting

View raw message