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 Mon, 03 Dec 2012 15:41:51 GMT
Hi,

On Mon, Dec 3, 2012 at 5:17 PM, Marcel Reutegger <mreutegg@adobe.com> wrote:
>> 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.

There are various potential scenarios where you might want to do
something like that. For example when modifying a node type, it would
be useful if I could also adjust all past versions of affected nodes
to match the new type definition. Otherwise I wouldn't be able to
check out those versions anymore.

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

One good example of a potential versioning operation that isn't
covered by JCR 2.0 is rebase, i.e. adjusting the base version of a
node without having to first restore that version and then re-apply
all changes.

It might be that we never need to support anything like that in
practice, but I'd rather design the system so that we don't need to
change the core implementation to support extensions like that.

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

One potential use case would be a "partial checkin" where we want to
create a new version with just a subset of the modified content in the
checked out node (like you can easily do with svn or git). Can we do
that without triggering a full checkin or checkpoint operation from a
content hook?

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

A remoting layer can be made to expose also higher level operations
above the Oak API. For example, if the versioning code was
encapsulated in something like a VersioningOperations utility class
the oak-http component could use it to provide direct HTTP access to
such versioning oprations. A remote oak-jcr client could then use
something like a VersioningOperationsOverHttp subclass to replace the
direct Oak API code with higher-level alternatives.

BR,

Jukka Zitting

Mime
View raw message