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: Oak & JCR versioning
Date Mon, 03 Dec 2012 15:17:21 GMT

> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> On Thu, Nov 29, 2012 at 3:11 PM, Marcel Reutegger
> <mreutegg@adobe.com> wrote:
> > now, to implement the various JCR versioning operations, I'd like
> > to encapsulate them in commit hooks as much as possible. this
> > avoid the need to duplicate code and perform consistency checks
> > in various places. my idea is to trigger those hooks with a defined
> > set of content modification on Trees on through the oak API:
> This might be troublesome in some cases, for example if we want to
> import a node together with its version history,

hmm, I didn't consider that case. Is this really something we want to
support? I don't think we had that feature in Jackrabbit.

alternatively this can also be achieved by running an import on top
of the MicroKernel or NodeStore API directly without any validators.

> or explicitly modify a version history

why would you want to do that? I think it is better to limit the possible
modifications to what the spec allows you to do.

> or a checked out node in ways that don't fit within
> the mentioned predefined operations. 

there wouldn't be any restrictions in this case. you can do whatever
you want with a checked out node. I probably missed something.
Can you describe in more detail what you mean here?

> I wouldn't want to run into cases
> where a client can't do something it wants because doing so would
> trigger unwanted content modifications by the commit hooks.

can you give an example?

> I'd rather just have a Validator that ensures that whatever you do,
> the version history and related bits are internally consistent and
> conform with whatever other constraints we have (location/structure of
> version histories, etc.). For example, when making a node versionable,
> already the mix:versionable node type requires the presence of
> relevant versioning properties, and the versioning validator could
> simply make sure that those properties point to existing and valid
> version history information.
> As for the code duplication argument, I'd take care of that simply by
> making the relevant code available as a reusable set of classes. See
> for example how the namespace and node type management code is
> handled.

yes, that would also work. though, it requires you to use those classes
on top of the oak-api when you want to provide remoting for version
operations. with my approach one could simply perform content
modifications on the oak api to trigger the version operations.


View raw message