jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tri...@day.com>
Subject Re: Recursive child versioning
Date Fri, 26 Mar 2010 20:47:12 GMT
On Fri, Mar 26, 2010 at 3:23 PM, Davide Maestroni
<davide.maestroni@gmail.com> wrote:
> Hi Tobias,
>
> what you wrote is perfectly right, however if you look at
> http://www.day.com/specs/jcr/1.0/8.2.11.2_VERSION.html (I have just
> copy/pasted from there), the versioning process described is a bit
> different.
> I really don't know if there is a bug or not, I'm just trying to clearly
> understand how the versioning works in Jackrabbit and which is the expected
> behavior in each case.
> Since it looks to me that JCR 1.0 and JCR 2.0 say slightly different
> things (but with huge impact) and I have observed the same behavior using
> Jackrabbit 1.0 and Jackrabbit 2.0, I am bit confused about how things should
> work.
> If you say that the versioning of a whole sub-tree depends only on the child
> node, and not on all its descendants, I am perfectly fine with that, I just
> want to be sure that what I see is correct, and my understanding of the
> specifications is correct as well.
yes. jcr2.0 is far more precise about the versioning. if i remember
correctly, in jackrabbit 1.0 the behavior was different, indeed.
jackrabbit 2.0 implements the versioning as described in jcr2.0

regards, toby

>
> Thanks,
>
> Davide
>
>
> On Fri, Mar 26, 2010 at 2:05 PM, Tobias Bocanegra <tripod@day.com> wrote:
>
>> hi,
>> that is not entirely true.
>>
>> if you checkin A, then B (and the entire subtree is copied, since B is
>> not versionable (irrespective of the OPV of B).
>>
>> 3.13.9 Versionable State
>> [...]
>> 5. For each child node C of N where
>> •       C has an OPV of COPY,
>> a copy of the entire subgraph rooted at C (regardless of the OPV
>> values of the sub-items) is added to the frozen node, preserving the
>> name of C and the names and values of all its sub-items.
>> [...]
>>
>> if you checkin B, then all C's should be not copied if they have a
>> OPV=VERSION:
>>
>> 3.13.9 Versionable State
>> [...]
>> 6. For each child node C of N where:
>> •       C has an OPV of VERSION
>> Under simple versioning, the same behavior as COPY. Under full
>> versioning, if C is not mix:versionable, the same behavior as
>> COPY.
>> Under full versioning, if C is mix:versionable, then a special
>> nt:versionedChild node with a reference to the version history of C is
>> substituted in place of C as a child of the frozen node.
>> [...]
>>
>> So you statement:
>> "... however the recursive copy terminates at each versionable node
>> encountered further below in the subtree, "
>>
>> is not correct. where did you read this?
>> regards, toby
>>
>>
>> On Wed, Mar 3, 2010 at 10:02 PM, Davide Maestroni
>> <davide.maestroni@gmail.com> wrote:
>> > Hi Alex,
>> >
>> > thank you for your suggestions, now I have a clearer idea about the
>> > versioning of child nodes.
>> > Though I still have one doubt. In my repository I have a parent-child
>> > structure like this:
>> >
>> > A (mix:versionable, nt:unstructured)
>> >      ^
>> >      |
>> > B (nt:unstructured)
>> >      ^
>> >      |
>> > C (mix:versionable, nt:unstructured)
>> >      ^
>> >      |
>> > D (nt:file)
>> >      ^
>> >      |
>> > E (nt:resource)
>> >
>> > Where the OnParentVersion attribute for child nodes, in the node type
>> > definition of A, B and C, is always VERSION.
>> > As per what written in paragraph 8.2.11.2 of JCR 1.0 specifications ("If
>> *C* is
>> > not versionable then the behavior of *COPY*applies on *checkin*, however
>> the
>> > recursive copy terminates at each versionable node encountered further
>> below
>> > in the subtree, at which points the standard *VERSION* behavior is again
>> > followed."), what I expect when versioning the node A is that D and E are
>> > not copied, but it is not what I observe. I looked also in JCR 2.0 but
>> > couldn't find anything explaining a different behavior.
>> > What am I missing here?
>> >
>> > Thanks again for your patience,
>> >
>> > Davide
>> >
>> >
>> >
>> > On Mon, Mar 1, 2010 at 10:31 PM, Alexander Klimetschek <aklimets@day.com
>> >wrote:
>> >
>> >> On Mon, Mar 1, 2010 at 22:28, Alexander Klimetschek <aklimets@day.com>
>> >> wrote:
>> >> > Also it is optimized for trees
>> >> > with fine-granular content (eg. a page in a CMS), not for arbitrary
>> >> > sized subfolders with lots of binary content.
>> >>
>> >> Ah, forgot: have you tried your scenario with a FileDataStore? Using a
>> >> datastore avoids duplicate binaries in the storage, so there should
>> >> only be some overhead in hashing the files upon versioning. Not sure,
>> >> it might be that the versioning implementation internally temporarily
>> >> copies the files, which might be slow.
>> >>
>> >> Regards,
>> >> Alex
>> >>
>> >> --
>> >> Alexander Klimetschek
>> >> alexander.klimetschek@day.com
>> >>
>> >
>>
>

Mime
View raw message