Details

    • Sub-task
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 3.5.8
    • 3.6.4
    • vlt
    • None

    Description

      Currently, according to the documentation (https://jackrabbit.apache.org/filevault/referenceablenodes.html), "IdConflictPolicy.FORCE_REMOVE_CONFLICTING_ID" is supposed to behave as 3.5.0 did.

      My tests show however that in 3.5.0, when importing a package with two nodes with conflicting UUIDs, both nodes were imported (and one of the UUIDs changed).

      Update: It turned out that this is only the conflict handling for non-sibling nodes, for sibling nodes the behaviour depends on whether the existing conflicting node is contained in the filter or not. If the newly imported node is a sibling of the existing conflicting it either removes the existing node with the conflicting id but keep its references (in case the conflicting one is contained in the filter) or skip the to be imported node (and continue with importing its children as if they were below the existing one).

      From that point of view, CREATE_NEW_ID seems to be closer (but that one assigns new UUIDs to both nodes).

      Proposal: adjust CREATE_NEW_ID behavior to keep assigning a new UUID only when needed (thus preserving it for one of the nodes), and document that mode as compatible to 3.5.0.

      Updated Proposal: Create new IdConflictPolicy.LEGACY which replicates the behaviour described above.

      Attachments

        1. test-duplicate-referencable-on-child-element-only.zip
          8 kB
          Konrad Windszus
        2. test-referenceable.zip
          6 kB
          Konrad Windszus

        Issue Links

          Activity

            People

              kwin Konrad Windszus
              reschke Julian Reschke
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: