jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Janssen <lars-listm...@ukmix.net>
Subject Re: Preview workflow based on workspace clone/node update
Date Thu, 09 May 2013 17:01:12 GMT
Hi David,

Thanks *very* much for looking into this and sharing your findings.

* cloned nodes share the version history, so checkins in either
> workspace go into the same history.

This is good to know, although am I right in thinking it shouldn't affect
my current workflow (make changes in a "preview" workspace, clone/update to
"published")? Note that I'm not currently using versioning, but intend to

My understanding then is that clone and update should work the same for a
node with mix:versionable as for one without (leaving children aside for a
moment). It's only when you use checkin, restore etc. that the shared
version history becomes apparent.

* when updating, jackrabbit at least is using this version history to
> destroy as little information as possible. so if a field was updated in
> the updating workspace but not in the one we update from, the changed
> field is kept.

I'm not sure if I understand this. Presumably for non-versionable nodes,
this simply doesn't apply. For versionable nodes, are you saying the update
operation looks at the version history and doesn't just compare the base
nodes in both workspaces?

Imagine this scenario:

- Create a (mix:referenceable, mix:versionable) Node N in workspace A
- Create a new version of N (checkin), so you have version 1.1 and the base
version (I think we can ignore the root version)
- Clone N into workspace B, giving a node N' in that workspace
  (look at the version history for either N or N', and you'll see the same
original version 1.1)
- Change a property of N, change the same property of N' to a different
- Now try to update N' with the changes from N... what happens?

That last part is what I don't understand. I haven't tested it, but I
thought that the changes from N would overwrite any changes in N'. Are you
saying that actually the version history is used somehow?

* jackrabbit currently checks children if they are mix:versionable and
> if so, skips them. so you could model your content as versionable for
> things that you do want to synchronize separately.
> it should be mix:simpleVersionable instead of mix:versionable, i think
> jukka created a patch for that, but this will at best come in the next
> 2.6 release. i *think* phpcr-odm is currently using
> mix:simpleVersionable, but i could be wrong here.

Do you mean that Jackrabbit skips mix:versionable nodes when performing an
update? Suppose I have nodes like this, where * means the node is


If I update "/page" from workspace A to workspace B, then should only the
following nodes be updated?


I have tried testing this using the phpcr-api-tests suite, with
mix:versionable and mix:simpleVersionable, and in both cases any changes to
"/page/sub-page" are copied across when I update "/page".



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message