jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davide Maestroni <davide.maestr...@gmail.com>
Subject Re: Recursive child versioning
Date Wed, 03 Mar 2010 21:02:54 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message