Hi, > From: Jukka Zitting [mailto:[email protected]] > On Tue, Dec 4, 2012 at 2:02 PM, Marcel Reutegger <[email protected]> > 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
