i created a JIRA issue: http://issues.apache.org/jira/browse/JCR-423
regards, toby On 5/2/06, Tobias Bocanegra <[EMAIL PROTECTED]> wrote:
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 <[EMAIL PROTECTED]> wrote: > Hi Toby, > > [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 > > > > > > > > > -- > > -----------------------------------------< [EMAIL PROTECTED] >--- > > 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 >--- > > -- -----------------------------------------< [EMAIL PROTECTED] >--- 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 >---
-- -----------------------------------------< [EMAIL PROTECTED] >--- 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 >---
