jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Oak & JCR versioning
Date Mon, 03 Dec 2012 16:17:11 GMT
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

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

View raw message