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 13:05:11 GMT
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