jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Bocanegra" <tobias.bocane...@day.com>
Subject Re: Versioning question
Date Fri, 17 Nov 2006 20:36:56 GMT
well, i'm not sure if we discussed this in the jackrabbit list or in
the jsr283 list. but since OPV=ignore properties/nodes are excluded in
the frozen state of a version anyways, they should be modifiable even
if the parent node is checked-in.

i opened a jira issue for further discussion.
http://issues.apache.org/jira/browse/JCR-639

regards, toby

On 11/16/06, James Hang <jhang@bea.com> wrote:
>
> I assume you would still need to checkout and create a new version of T1
> everytime you want to modify T2,T3 nodes.  I'd like to be able to modify
> T2,T3 nodes completely indepedent of T1...
>
>
>
> Tobias Bocanegra wrote:
> >
> > so you want T2,T3:
> > - not versionable
> > - ignored by T1
> > - but not overridden on restore of T1
> >
> > but this should be possible with OPV=Ignore and 'removeExisting=false'
> > on restore.
> >
> > regards, toby
> >
> > On 11/15/06, James Hang <jhang@bea.com> wrote:
> >>
> >> What if I don't want T2 and T3 to have version history at all?  So that I
> >> can
> >> modify them as independent non-versionable nodes (no checkout/checkin
> >> required).  Is this possible to do?  I guess maybe what might make more
> >> sense in my case is if I just put T2 and T3 nodes outside of the T1
> >> hierarchy and just have a references to them....
> >>
> >>
> >>
> >> Tobias Bocanegra wrote:
> >> >
> >> > yes, there is: you need to make them: OnParentVersion = VERSION.
> >> > this means, that their existence is recorded in version of T1 but not
> >> > there contents (if they are mix:versionable, also) i know the
> >> > versioning section in jsr170 is a bit confusing, but after having read
> >> > it 20 times, i start to understand it :-)
> >> >
> >> > regards, toby
> >> >
> >> >
> >> > On 11/15/06, James Hang <jhang@bea.com> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> I have a question about versioning, in particular how you would create
> >> >> child
> >> >> nodes of a versioned node that are not versioned with the parent and
> >> can
> >> >> be
> >> >> modified entirely independent of its parent.
> >> >>
> >> >> For example, let's say I have a type T1. Nodes of T1 can have child
> >> nodes
> >> >> of
> >> >> type T2.  Nodes of type T2 can have child nodes of type T3.
> >> >>
> >> >> So, my node tree will be like this:
> >> >>
> >> >> T1
> >> >> |_
> >> >>     T2 ...
> >> >>     |_
> >> >>         T3 ...
> >> >>
> >> >> Now, let's say that I want to make it so that when I create a new
> >> version
> >> >> of
> >> >> T1, I don't want T2 or its descendents to be part of the state that
> >> >> version.
> >> >> One way I can do this by making the onParentVersion attribute of T2
> >> and
> >> >> T3
> >> >> to be IGNORE.  However, in order to modify the T3 nodes, I will still
> >> >> have
> >> >> to checkout/checkin a new version of its T1 ancestor.  Is there a way
> >> to
> >> >> avoid this?
> >> >>
> >> >> I understand that adding/deleting T2 nodes will have to require
> >> checking
> >> >> out
> >> >> T1, since the state of T1 will have to be modified.  But it seems like
> >> >> you
> >> >> should be able to modify T2 properties and add/delete T3 nodes without
> >> >> having to do a checkout.  Essentially, is there a way to make T2/T3
> >> nodes
> >> >> act like non-versionable standalone nodes, even though they are part
> >> of
> >> >> the
> >> >> node hierarchy of a versionable node?
> >> >>
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >> http://www.nabble.com/Versioning-question-tf2633512.html#a7350349
> >> >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > -----------------------------------------< tobias.bocanegra@day.com
> >> >---
> >> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> >> > T +41 61 226 98 98, F +41 61 226 98 97
> >> > -----------------------------------------------< http://www.day.com
> >> >---
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Versioning-question-tf2633512.html#a7361482
> >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > -----------------------------------------< tobias.bocanegra@day.com >---
> > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> > T +41 61 226 98 98, F +41 61 226 98 97
> > -----------------------------------------------< http://www.day.com >---
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Versioning-question-tf2633512.html#a7389860
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>


-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Mime
View raw message