jsr-283
  1. jsr-283
  2. JSR_283-795

Clarify VersionManager.createConfiguration()

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: versioning
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      795

      Description

      i'm not very sure about the meaning of VersionManager.createConfiguration(String absPath, Version
      baseline) in the case when "baseline" is not null.

      assume you already have a configuration in the workspace rooted a N, the nt:configuration node C in
      the jcr:configurations storage, and C's version history VH and baseline B1.

      assume you want to create a new configuration of a tree rooted at N'. what should happen on creation
      of a new configuration of N' with passing baseline B1 ?

      according to the spec, a new configuration C' is created, sharing the version history VH and using B1.
      then, for example a subsequent checkin of N' would then record all base versions below N' in B2, and a
      checkin of N would record all base versions below N in a version B3. i don't think that this would be
      valid.

      so, what should be the meaning of the baseline parameter?

        Activity

        Hide
        tripod added a comment -

        ok with removing the baseline argument for createConfiguration. the lesser possibilities to achieve the
        same result, the better.

        Show
        tripod added a comment - ok with removing the baseline argument for createConfiguration. the lesser possibilities to achieve the same result, the better.
        Hide
        geoffreyclemm added a comment -

        It occured to me that VM.restore(path, baseline, removeExisting) does not make
        sense if path identifies an nt:configuration node (because then the path is
        redundant ... VM.restore(baseline) is sufficient. So when VM.restore(path,
        baseline, removeExisting) is used, the path always identifies the location at
        which the root of the restored configuration should be located. I'll submit a
        new issue for this, because it holds in general for VM.restore(path, version,
        removeExisting) ... i.e. it should be an error if a versionable node for the
        version history of version already exists in the workspace.

        Show
        geoffreyclemm added a comment - It occured to me that VM.restore(path, baseline, removeExisting) does not make sense if path identifies an nt:configuration node (because then the path is redundant ... VM.restore(baseline) is sufficient. So when VM.restore(path, baseline, removeExisting) is used, the path always identifies the location at which the root of the restored configuration should be located. I'll submit a new issue for this, because it holds in general for VM.restore(path, version, removeExisting) ... i.e. it should be an error if a versionable node for the version history of version already exists in the workspace.
        Hide
        Peeter Piegaze added a comment -

        Fixed

        Show
        Peeter Piegaze added a comment - Fixed
        Hide
        tripod added a comment -

        the VersionManager.java still needs to be adjusted for the new signature, e.g.:

        /**

        • Calling <code>createConfiguration</code> on the node <i>N</i> at
        • <code>absPath</code> creates, in the configuration storage, a new
        • <code>nt:configuration</code> node whose root is <i>N</i>. A reference to
        • <i>N</i> is recorded in the <code>jcr:root</code> property of the new
        • configuration, and a reference to the new configuration is recorded in
        • the <code>jcr:configuration</code> property of <i>N</i>.
        • <p>
        • The changes are dispatched immediately; a <code>save</code> is not
        • required.
          *
        • @param absPath an absolute path.
        • @return a new <code>nt:configuration</code> node
        • @throws UnsupportedRepositoryOperationException
        • if <i>N</i> is not
        • versionable.
        • @throws RepositoryException if another error occurs.
        • @since JCR 2.0
          */
          public Node createConfiguration(String absPath) throws UnsupportedRepositoryOperationException,
          RepositoryException;

        maybe also add some text to the javadoc about when this method will fail.

        Show
        tripod added a comment - the VersionManager.java still needs to be adjusted for the new signature, e.g.: /** Calling <code>createConfiguration</code> on the node <i>N</i> at <code>absPath</code> creates, in the configuration storage, a new <code>nt:configuration</code> node whose root is <i>N</i>. A reference to <i>N</i> is recorded in the <code>jcr:root</code> property of the new configuration, and a reference to the new configuration is recorded in the <code>jcr:configuration</code> property of <i>N</i>. <p> The changes are dispatched immediately; a <code>save</code> is not required. * @param absPath an absolute path. @return a new <code>nt:configuration</code> node @throws UnsupportedRepositoryOperationException if <i>N</i> is not versionable. @throws RepositoryException if another error occurs. @since JCR 2.0 */ public Node createConfiguration(String absPath) throws UnsupportedRepositoryOperationException, RepositoryException; maybe also add some text to the javadoc about when this method will fail.
        Hide
        Peeter Piegaze added a comment -

        Fixed

        Show
        Peeter Piegaze added a comment - Fixed

          People

          • Assignee:
            jsr-283-issues
            Reporter:
            tripod
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: