Oak & JCR versioning

[Marcel Reutegger <mr...@adobe.com>]

hi all,

during the last oak hackathon in basel a couple of people started a
discussion how to implement JCR versioning in oak. I'd like to give
a quick overview what was discussed and how I think we could implement
the various version related operations in oak.

to properly support JCR versioning we will have to make the version
store available to all workspaces in oak. though, right now we don't
even support multiple workspaces in oak. this means in a first step
we will probably have to implement multi-workspace support by
moving the current workspace tree one level down the hierarchy.
the version store could then simply become a special workspace
that will be made visible under /jcr:system/jcr:versionStorage. during
the hackathon we discussed multiple options how to make the versions
appear at that location:

- the version store is mounted at the NodeState level. this has the
advantage of being easier to implement, because the API is rather
small. it would also allow us to enforce write protection on the version
store by exposing it read-only at this location.

- the version store is mounted on a higher level. that is, oak-jcr is
responsible for constructing the node tree correctly as required
by the JCR spec. this way it might be easier to separate JCR concerns
from oak core and keep the latter as simple as possible.

no matter which approach we take the version storage will be
persisted as oak Trees ;)

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:

= making a node versionable / create an initial version history

a node is made versionable by adding a mix:versionable mixin type
or by creating a node with a primary type that extends from mix:versionable.
a commit hook will detect these modifications and create a version
history for that node. in addition it will also modify the versionable
node and set appropriate values for jcr:baseVersion, jcr:isCheckedOut,
jcr:versionHistory, etc. this is very similar to how the current Jackrabbit
implementation works.

= checkin / checkout

the jcr:isCheckedOut Boolean property is flipped and the change is
saved. a commit hook will be triggered by this change and perform
either a checkin or checkout operation. e.g. on checkin a version is created
in the version store and the version related properties on the versionable
node are updated accordingly. any other modification on a previously
checked in node is rejected by the commit hook. at the same time
oak-jcr will of course respect the jcr:isCheckedOut value and prevent
changes when the node is checked in.

= checkpoint

an easy implementation could simply perform a checkin followed by
a checkout. though, this wouldn't be 100% correct because it's not
atomic.

= restore version

on the versionable node the jcr:baseVersion is set and save is called.
a commit hook will be triggered by this change and perform the
actual restore.
handling of removeExisting: oak-jcr takes care of this flag and removes
existing nodes if requested and necessary. the version restore commit
hook will always fail if it encounters an identifier collision.
restoring a node that doesn't exist in the workspace (15.7.8): create
node with type stored in jcr:frozenPrimaryType of version to restore.
jcr:baseVersion identifies version to restore. on save, the commit hook
will restore the rest of the version.

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

= merge

this operation may work similar to version label manipulation and removing
a version. setting a version operation property on the versionable
node triggers a commit hook, which performs the actual operation and
removes the property on save.

feedback is very welcome ;)

regards
 marcel

RE: Oak & JCR versioning

[Marcel Reutegger <mr...@adobe.com>]

Hi,

> apart from that i am bit confused by your description of the
> different versioning operations. you write that changes are
> being saved...

sorry, that was indeed confusing. In most cases I was referring 
to the Oak API where Root.commit() is called to 'save' changes.

regards
 marcel

Re: Oak & JCR versioning

[Angela Schreiber <an...@adobe.com>]

hi marcel

i would go for variant 1. making oak-jcr very complex in order
to keep oak-core simple is the wrong approach IMO and contradicts
the original goal of making it very simple to implement a
jcr-like client on top of oak without having to take care
of complex stuff such as node types, versioning and so on...
that doesn't necessarily mean that we need to extend the OAK-API...
but i think the logic should be part of the oak-core project
rather than with oak-jcr.

apart from that i am bit confused by your description of the
different versioning operations. you write that changes are
being saved... i would in any case avoid writing transient
modifications to the session and persist them using Session#save().
instead i would rather use the same mechanism as is currently
used by other workspace operations as we should never have
transient modifications pending if - for whatever reason - a
workspace (version) operations fails.

kind regards
angela

On 11/29/12 3:11 PM, Marcel Reutegger wrote:
> hi all,
>
> during the last oak hackathon in basel a couple of people started a
> discussion how to implement JCR versioning in oak. I'd like to give
> a quick overview what was discussed and how I think we could implement
> the various version related operations in oak.
>
> to properly support JCR versioning we will have to make the version
> store available to all workspaces in oak. though, right now we don't
> even support multiple workspaces in oak. this means in a first step
> we will probably have to implement multi-workspace support by
> moving the current workspace tree one level down the hierarchy.
> the version store could then simply become a special workspace
> that will be made visible under /jcr:system/jcr:versionStorage. during
> the hackathon we discussed multiple options how to make the versions
> appear at that location:
>
> - the version store is mounted at the NodeState level. this has the
> advantage of being easier to implement, because the API is rather
> small. it would also allow us to enforce write protection on the version
> store by exposing it read-only at this location.
>
> - the version store is mounted on a higher level. that is, oak-jcr is
> responsible for constructing the node tree correctly as required
> by the JCR spec. this way it might be easier to separate JCR concerns
> from oak core and keep the latter as simple as possible.
>
> no matter which approach we take the version storage will be
> persisted as oak Trees ;)
>
> 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:
>
> = making a node versionable / create an initial version history
>
> a node is made versionable by adding a mix:versionable mixin type
> or by creating a node with a primary type that extends from mix:versionable.
> a commit hook will detect these modifications and create a version
> history for that node. in addition it will also modify the versionable
> node and set appropriate values for jcr:baseVersion, jcr:isCheckedOut,
> jcr:versionHistory, etc. this is very similar to how the current Jackrabbit
> implementation works.
>
> = checkin / checkout
>
> the jcr:isCheckedOut Boolean property is flipped and the change is
> saved. a commit hook will be triggered by this change and perform
> either a checkin or checkout operation. e.g. on checkin a version is created
> in the version store and the version related properties on the versionable
> node are updated accordingly. any other modification on a previously
> checked in node is rejected by the commit hook. at the same time
> oak-jcr will of course respect the jcr:isCheckedOut value and prevent
> changes when the node is checked in.
>
> = checkpoint
>
> an easy implementation could simply perform a checkin followed by
> a checkout. though, this wouldn't be 100% correct because it's not
> atomic.
>
> = restore version
>
> on the versionable node the jcr:baseVersion is set and save is called.
> a commit hook will be triggered by this change and perform the
> actual restore.
> handling of removeExisting: oak-jcr takes care of this flag and removes
> existing nodes if requested and necessary. the version restore commit
> hook will always fail if it encounters an identifier collision.
> restoring a node that doesn't exist in the workspace (15.7.8): create
> node with type stored in jcr:frozenPrimaryType of version to restore.
> jcr:baseVersion identifies version to restore. on save, the commit hook
> will restore the rest of the version.
>
> = 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.
>
> = merge
>
> this operation may work similar to version label manipulation and removing
> a version. setting a version operation property on the versionable
> node triggers a commit hook, which performs the actual operation and
> removes the property on save.
>
> feedback is very welcome ;)
>
> regards
>   marcel

Re: Oak & JCR versioning

[Angela Schreiber <an...@adobe.com>]

hi marcel

>> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
>> On Thu, Nov 29, 2012 at 3:11 PM, Marcel Reutegger
>> <mr...@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.

we didn't have it in jackrabbit but something that i discussed
multiple times with tobi... using JCR API (and jackrabbit) the only
way to do that would be a workspace import which on the other hand
wasn't supported for other special content... now with the OAK API
in between we definitely should reconsider that as importing
protected content can be handled straight forward both as session
and as workspace operation.

kind regards
angela

RE: Oak & JCR versioning

[Marcel Reutegger <mr...@adobe.com>]

Hi,

> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> On Wed, Dec 5, 2012 at 12:18 PM, Marcel Reutegger
> <mr...@adobe.com> wrote:
> > sounds good to me. though, I initially didn't plan to implement a Validator
> > at all ;) the CommitHook should ensure that the modifications it does are
> > consistent. but yes, better safe than sorry...
> 
> OK. We can start with a pretty trivial VersionValidator that for
> example just verifies that the jcr:baseVersion references a nt:version
> node within the correct nt:versionHistory node referenced by the
> jcr:versionHistory property. It perhaps could also sure that a
> specific version label occurs only once within a version history. Most
> of the remaining essential validation should already come from the
> TypeValidator.

you are right, I didn't think of the TypeValidator. That should already cover
for quite some cases. i.e. all the static constraints that are described by the
version related node type.

Regards
 Marcel

Re: Oak & JCR versioning

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Wed, Dec 5, 2012 at 12:18 PM, Marcel Reutegger <mr...@adobe.com> wrote:
> see also the 'workspaces & version storage' thread. there I came to the
> conclusion it's better to separate (at least from a read-only perspective).
> I think it makes future implementation of multiple workspaces easier.

I see the point, but note the constraint on the jcr:versionHistory and
jcr:baseVersion reference properties I just mentioned in that thread.
Let's follow up there.

> sounds good to me. though, I initially didn't plan to implement a Validator
> at all ;) the CommitHook should ensure that the modifications it does are
> consistent. but yes, better safe than sorry...

OK. We can start with a pretty trivial VersionValidator that for
example just verifies that the jcr:baseVersion references a nt:version
node within the correct nt:versionHistory node referenced by the
jcr:versionHistory property. It perhaps could also sure that a
specific version label occurs only once within a version history. Most
of the remaining essential validation should already come from the
TypeValidator.

BR,

Jukka Zitting

RE: Oak & JCR versioning

[Marcel Reutegger <mr...@adobe.com>]

> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> 
> On Wed, Dec 5, 2012 at 9:19 AM, Marcel Reutegger <mr...@adobe.com>
> wrote:
> > 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.
> 
> I think in either case the version storage should be exposed simply as
> the /jcr:system/jcr:versionStorage subtree.

see also the 'workspaces & version storage' thread. there I came to the
conclusion it's better to separate (at least from a read-only perspective).
 I think it makes future implementation of multiple workspaces easier.

> Anyway, how about we go with your option 1), but structure the code
> such that we keep the CommitHook that triggers versioning operations
> separate from a Validator that simply ensures the consistency of
> changes to the version store and all versionable nodes (and would
> therefore also act as an independent watchdog for potential bugs in
> the hook)? That way potential future deployments that want more
> freedom at the expense of more complicated versioning could achieve
> that simply by disabling the auto-versioning CommitHook.

sounds good to me. though, I initially didn't plan to implement a Validator
at all ;) the CommitHook should ensure that the modifications it does are
consistent. but yes, better safe than sorry...

regards
 marcel

Re: Oak & JCR versioning

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Wed, Dec 5, 2012 at 9:19 AM, Marcel Reutegger <mr...@adobe.com> wrote:
> 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.

I think in either case the version storage should be exposed simply as
the /jcr:system/jcr:versionStorage subtree.

Anyway, how about we go with your option 1), but structure the code
such that we keep the CommitHook that triggers versioning operations
separate from a Validator that simply ensures the consistency of
changes to the version store and all versionable nodes (and would
therefore also act as an independent watchdog for potential bugs in
the hook)? That way potential future deployments that want more
freedom at the expense of more complicated versioning could achieve
that simply by disabling the auto-versioning CommitHook.

BR,

Jukka Zitting

RE: Oak & JCR versioning

[Marcel Reutegger <mr...@adobe.com>]

Hi,

> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> On Tue, Dec 4, 2012 at 2:02 PM, Marcel Reutegger <mr...@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

Re: Oak & JCR versioning

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Dec 4, 2012 at 2:02 PM, Marcel Reutegger <mr...@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
consistency.

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

BR,

Jukka Zitting

RE: Oak & JCR versioning

[Marcel Reutegger <mr...@adobe.com>]

Hi,

> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> On Mon, Dec 3, 2012 at 5:17 PM, Marcel Reutegger <mr...@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.

regards
 marcel

Re: Oak & JCR versioning

[Jukka Zitting <ju...@gmail.com>]

Hi,

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

RE: Oak & JCR versioning

[Marcel Reutegger <mr...@adobe.com>]

Hi,

> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> On Thu, Nov 29, 2012 at 3:11 PM, Marcel Reutegger
> <mr...@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.

regards
 marcel

Re: Oak & JCR versioning

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Thu, Nov 29, 2012 at 3:11 PM, Marcel Reutegger <mr...@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, or explicitly modify
a version history or a checked out node in ways that don't fit within
the mentioned predefined operations. 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.

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.

BR,

Jukka Zitting

Re: Oak & JCR versioning

[Alexander Klimetschek <ak...@adobe.com>]

On 29.11.2012, at 15:11, Marcel Reutegger <mr...@adobe.com> wrote:

> - the version store is mounted at the NodeState level. this has the
> advantage of being easier to implement, because the API is rather
> small. it would also allow us to enforce write protection on the version
> store by exposing it read-only at this location.
> 
> - the version store is mounted on a higher level. that is, oak-jcr is
> responsible for constructing the node tree correctly as required
> by the JCR spec. this way it might be easier to separate JCR concerns
> from oak core and keep the latter as simple as possible.

With my distant, high-level view on this, I'd definitely opt for the second option. While versioning might be efficiently built into the deeper persistence layers, the specific jcr versioning model(s) should not bloat oak right from the beginning and rather sit separate on top.

my 2 cents,
Alex

Re: Oak & JCR versioning

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, Nov 30, 2012 at 11:03 AM, Lukas Kahwe Smith <ml...@pooteeweet.org> wrote:
> its my understanding that workspaces are one of the viable approaches to content staging.

Right. That's one of the big use cases for versioning in JCR. Without
workspaces the versioning feature is significantly limited (and
simplified). However, I know only a couple of isolated deployments
where this feature is used in practice. In Adobe's CQ we use a custom
replication mechanism for staging, so we don't have a direct need to
use versioning for this purpose.

> its also useful for multi tenant setups. especially if we are to bring JCR and Oak
> to larger audiences via PHPCR, then we also need to consider how to make it
> easier to host for people with lower requirements than the average Java based
> CMS installation.

Multiple workspaces for multi-tenant setups are much easier to
implement, as there we can (and should) map each workspace to a
completely separate content tree (no shared version storage, node
types, etc.). In the MongoMK case we could for example map the
workspace name to the name of the MongoDB database being accessed.

Such a workspace model would be much easier to implement than full JCR
workspace support (with all the cross-workspace operations), but might
already cover most of the potential use cases apart from content
staging.

BR,

Jukka Zitting

Re: Oak & JCR versioning

[Lukas Kahwe Smith <ml...@pooteeweet.org>]

On Nov 30, 2012, at 10:58 , KÖLL Claus <C....@TIROL.GV.AT> wrote:

> Hi ...
> 
> With respect to your experience over times but i'm absolutly sure that there are many use cases out there
> where workspaces will be used.
> 
> I don't know exactly of which level we are talking here but on jcr (api) level workspaces are from my point of view
> a must have.


its my understanding that workspaces are one of the viable approaches to content staging.

its also useful for multi tenant setups. especially if we are to bring JCR and Oak to larger audiences via PHPCR, then we also need to consider how to make it easier to host for people with lower requirements than the average Java based CMS installation.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

AW: Oak & JCR versioning

[KÖLL Claus <C....@TIROL.GV.AT>]

Hi ...

With respect to your experience over times but i'm absolutly sure that there are many use cases out there
where workspaces will be used.

I don't know exactly of which level we are talking here but on jcr (api) level workspaces are from my point of view
a must have.

greets
claus

Re: Oak & JCR versioning

[Michael Dürig <md...@apache.org>]

On 30.11.12 9:01, Bertrand Delacretaz wrote:
> Hi,
>
> On Thu, Nov 29, 2012 at 3:11 PM, Marcel Reutegger <mr...@adobe.com> wrote:
>> ...to properly support JCR versioning we will have to make the version
>> store available to all workspaces in oak. though, right now we don't
>> even support multiple workspaces in oak. this means in a first step
>> we will probably have to implement multi-workspace support...
>
> Peanut gallery question, does Oak really need workspaces?

Good point! We discussed workspaces at lengths already: 
http://markmail.org/message/n2q3sesm2efeyzfk and 
https://issues.apache.org/jira/browse/OAK-118. Since we weren't able to 
come up with a consensus on how to implement them, we just left them out 
for the time being.

Michael

>
> In five years of JCR usage I have never used them, so depending on
> complexity it might be worth checking if they're actually needed.
>
> -Bertrand
>

Re: Oak & JCR versioning

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Thu, Nov 29, 2012 at 3:11 PM, Marcel Reutegger <mr...@adobe.com> wrote:
> ...to properly support JCR versioning we will have to make the version
> store available to all workspaces in oak. though, right now we don't
> even support multiple workspaces in oak. this means in a first step
> we will probably have to implement multi-workspace support...

Peanut gallery question, does Oak really need workspaces?

In five years of JCR usage I have never used them, so depending on
complexity it might be worth checking if they're actually needed.

-Bertrand