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 Fri, 26 Mar 2010 14:23:44 GMT
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.

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message