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 Mon, 29 Mar 2010 08:24:39 GMT
Hi Tobias and all,

thank you very much for your support. Your help has been very precious,
everything is clear now on my side, and I see that Jackrabbit 2.0 implements
exactly what described in JCR 2.0. I will structure my repository
accordingly.

Regards,

Davide


On Fri, Mar 26, 2010 at 9:47 PM, Tobias Bocanegra <tripod@day.com> wrote:

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