jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Buchmann <da...@liip.ch>
Subject Re: Preview workflow based on workspace clone/node update
Date Fri, 10 May 2013 16:09:50 GMT
> * 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)
(yep, root version has no properties anyways)
> - 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
> value
> - 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?

not sure how "conflicts" are handled. but what would be handled
correctly is if after cloning i do N.b = "y" then N.b would not be
overwritten on update N from N'. without versioning, JCR would have no
clue which would be newer if N'.b and N.b are different.

> * 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
> versionable:
> 
> /page*
> /page/block-1
> /page/block-2
> /page/sub-page*
> /page/sub-page/block-1
> /page/sub-page/block-2
> 
> If I update "/page" from workspace A to workspace B, then should only the
> following nodes be updated?
> 
> /page*
> /page/block-1
> /page/block-2
> 
> 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".

note that simpleVersionable is not identical to versionable. jackrabbit
has (or at least had until and including 2.6.0) the bug that it only
skips mix:versionable but not mix:simpleVersionable.

but what you describe is what i would expect from how jukka explained it
to me, yes.

cheers,david
-- 
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch

Mime
View raw message