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 Tue, 04 Dec 2012 13:02:38 GMT

> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> 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.

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 :-/

trivial node type changes would still be OK because no changes are
required on frozen nodes.

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

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

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 ;) 

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

right, we'd have to introduce yet another plugin mechanism in oak-http.
but we might have to do that anyway...

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.
at least at this stage we wouldn't have to deal with changes that affect
a workspace and the version store.


View raw message