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 <aklim...@day.com>wrote:
> On Mon, Mar 1, 2010 at 22:28, Alexander Klimetschek <aklim...@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.klimetsc...@day.com
>
