jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zoltan Farkas <zolyfar...@yahoo.com>
Subject Re: question about jackrabbit 2.1.1 versioning unextected behavior
Date Wed, 08 Sep 2010 14:32:19 GMT
From my understanding onparentversion is by default "COPY" so my initial tests were with copy.

I have made some experiments when I use "Version" instead, in this case restoring from version
1.5 to 1.0 seems to work, however restoring back to 1.5 gives a "unable to select appropriate
version for subconfigs using dateversionselector


On Sep 8, 2010, at 6:40 AM, Zoltan Farkas <zolyfarkas@yahoo.com> wrote:

> OnParentVersion was not set at all. Do I need a specific setting?
> I could use separate names, how can I define the node type to allow a unspecified number
of child nodes?
> --zoly
> On Sep 8, 2010, at 3:48 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>> Hi,
>> On Tue, Sep 7, 2010 at 9:04 PM, Zoltan Farkas <zolyfarkas@yahoo.com> wrote:
>>> The problem is that when restoring a node to a specific version, some
>>> of the subnodes are not restored properly.
>> Just checking: the OnParentVersion attribute of the child nodes is set
>> to COPY, right?
>>> Could this be a persistence specific issue?
>> Sounds unlikely. The logic of correctly handling same-name siblings in
>> complex operations like version restore is pretty challenging, so I
>> wouldn't be surprised if there's a bug lurking there somewhere. As a
>> workaround, is it possible for you to use separate names for all the
>> my:SubConfig nodes?
>> See JCR-43 [1] for an old, possibly related issue. It could no longer
>> be reproduced in Jackrabbit 1.6, but you may want to look at extending
>> the RestoreSameNameSiblingTest class to see if you can reproduce your
>> problem.
>> [1] https://issues.apache.org/jira/browse/JCR-43
>> BR,
>> Jukka Zitting

View raw message