jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Hang <jh...@bea.com>
Subject Re: Versioning question
Date Fri, 17 Nov 2006 21:17:18 GMT

Thanks for opening up this discussion.  I would definitely like this to
feature to be implemented in Jackrabbit.  It would seem like the logical way
for Jackrabbit to behave.  

Do you know if the JSR170 (or 283) spec mentions anything regarding this?  I
couldn't find anything myself.

Thanks,
James


Tobias Bocanegra wrote:
> 
> 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 >---
> 
> 

-- 
View this message in context: http://www.nabble.com/Versioning-question-tf2633512.html#a7411240
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.


Mime
View raw message