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 Wed, 05 Dec 2012 08:19:59 GMT
Hi,

> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> 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'm not so sure if that's really desirable. see also below.

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

I think the latter is the tricky part. You mentioned node type modifications
in the context of version storage. while we could say it's a permissible
operation to change a node type definition and at the same time update
the versionable node with its complete version history, this stands in sharp
contrast with the JCR specification. The JCR API does not allow this kind
of operation. I'm not too confident that we understand all the implications.
That's why I was referring to pandora's box...

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

I think it's better people either use JCR on Oak as is or use Oak directly
without any of the JCR extensions (validators, etc.). In the latter case
you are completely free to do with the repository whatever you like.

> > 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
> VersionHistory.removeVersion()?

from my initial message:

> = version labels, remove a version
> 
> these two are a bit tricky because changes are only reflected in the
> version storage, but not on the versionable node. the idea I have
> in mind is to set something like a temporary version operation property
> on the versionable node. e.g. rep:addVersionLabel = '<uuid>:foo'
> but this only works when the versionable node is actually present
> in the workspace, which doesn't need to be the case. specifically in
> the 'remove version' case where you might want to delete a complete
> version history, you first have to remove the versionable node in
> the workspace first. maybe version label manipulation and removing
> versions can work with operation properties on the jcr:versionStorage
> node? in any case such a property will be removed again by the
> commit hook, which would perform the requested operation.

I don't particularly like above approach, but it should work reasonably well
and is easy to use.

let's summarize. we seem to have two rather different proposals at the
moment.

1) restrict modifications to the version store to the ones specified in JCR.
version related operations are all done in commit hooks and triggered
in oak-jcr with simple content modifications. the version storage may
be exposed read-only.

- pros: easy to use for oak api client (does not require additional classes).
(automatic [0]) commit retry is more simple because commit hook
changes are discarded and rebasing the modification to trigger the version
operation is usually trivial. version storage can be read-only.

- cons: implementation is restrictive and only allows version manipulations
as defined by the JCR spec. 

2) version storage as exposed through the oak API is writable. a client,
including oak-jcr, can modify version histories in any possible way the
Oak API allows. A validator checks if the after commit state is consistent,
otherwise the commit is rejected. the validator and oak-jcr will probably
use common classes to perform content modifications and validation.

- pros: very flexible and allows for bulk version manipulations that go beyond
the JCR spec.

- cons: requires [1] utility classes to perform content updates for version
operations. requires defensive programming in the validator and probably
all version related classes (e.g. validator must detect broken version storage).
version storage must be writable.

I guess in the end I can live with either approach, but right now prefer
1). maybe the tie-breaker could be the question how we actually want to
expose the version storage through the Oak API and how we implement it.
if the implementation is easier with a read-only version storage (as seen
by the Oak API client), then I'd say we go with 1). I'll start a new thread
about this...

regards
 marcel

[0] I assume/hope we will have that at some point.
[1] well, not strictly, but otherwise you quickly duplicate code

Mime
View raw message