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 <[email protected]> wrote: > On Fri, Mar 26, 2010 at 3:23 PM, Davide Maestroni > <[email protected]> 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 <[email protected]> > 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 > >> <[email protected]> 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 < > [email protected] > >> >wrote: > >> > > >> >> On Mon, Mar 1, 2010 at 22:28, Alexander Klimetschek < > [email protected]> > >> >> 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 > >> >> [email protected] > >> >> > >> > > >> > > >
