jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Bocanegra" <tobias.bocane...@day.com>
Subject Re: Restore of node with child node having onParentVersion=VERSION fails
Date Tue, 02 May 2006 13:54:59 GMT
oh, ok. i see. you're talking of restore of an existing node. that
would be a bug then :-)

On 5/2/06, David Kennedy <davek@us.ibm.com> wrote:
> Hi Toby,
>
> tobias.strasser@gmail.com wrote on 05/02/2006 02:14:48 AM:
>
> > hi david,
> > you need to checkin that childnode aswell, before you are able to
> > restore the node. otherwise, there is no version you can restore from.
> > since the rootversion is only a sentinel of the version history, it
> > cannot be restored from.
>
> But the child node definition has onParentVersion=VERSION.  According to
> the spec....
>
> "On restore of VN, if the workspace currently has an already existing node
> corresponding to C?s version history and the removeExisting flag of the
> restore is set to true, then that instance of C becomes the child of the
> restored N."
>
> Since the workspace has the existing child, that child should become the
> child of the restored parent (i.e. nothing should really be restored from
> version history).  IMO, the restore should work the opposite of the
> checkin.  If I checkin a parent and it has a child with
> onParentVersion=VERSION, and that checkin merely causes a reference to the
> versionHistory of the child, then on restore, there is nothing to restore
> *unless* there is no child in the workspace at which point it would pull
> the "latest" from versionHistory.
>
> David
>
> >
> > regards, toby
> >
> > On 5/1/06, David Kennedy <davek@us.ibm.com> wrote:
> > > I have a node whose definition has properties and child nodes.  The
> > > definitions of the nodetypes for the node and the child include
> > > mix:versionable.  The properties definitions have onParentVersion=COPY
> and
> > > the child nodes have onParentVersion=VERSION.  When I create a node
> with
> > > child nodes and checkin and then restore the node, I get a
> > > "....VersionException: Restore of root node not allowed"  This is
> > > occurring on the restore of the child node.
> > >
> > > According to the spec:
> > >
> > > Child Node
> > > On checkin of N, the node VN will get a subnode of type
> nt:versionedChild
> > > with the same name as C. The single property of this node,
> > > jcr:childVersionHistory is a REFERENCE to the version history of C
> (not to
> > > C or any actual version of C). This also requires that C itself be
> > > versionable (otherwise it would not have a version history).
> > > .
> > > .
> > > .
> > > On restore of VN, if the workspace currently has an already existing
> node
> > > corresponding to C?s version history and the removeExisting flag of
> the
> > > restore is set to true, then that instance of C becomes the child of
> the
> > > restored N. If the workspace currently has an already existing node
> > > corresponding to C?s version history and the removeExisting flag of
> the
> > > restore is set to false then an ItemExistsException is thrown.
> > >
> > >
> > > I'm restoring the node using
> > >
> > >     node.restore(version, true);
> > >
> > > Is this expected behavior?
> > >
> > > David
> > >
> >
> >
> > --
> > -----------------------------------------< 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 >---
>
>


--
-----------------------------------------< 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