jsr-283
  1. jsr-283
  2. JSR_283-173

Support multiple property definitions for a specific name

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: current
    • Fix Version/s: early draft
    • Component/s: node types
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      173
    • Status Whiteboard:
      Hide

      RC4

      Show
      RC4

      Description

      From Tobi,
      i made the subject more general, since this is a general issue of property
      defnitions, that also affects the property types.

      i'm strongly against limiting this. it might need a bit more magic in some
      repository implementations, but it offers a lot of flexibility. and as i
      mentioned before, there are already jsr170 applications out there, that define
      nodetypes with multiple propdefs. btw: jackrabbit supports this.

      i would be ok with making this optional i.e. having a descirptor:
      OPTION_MULTIDEFS_SUPPORTED

      Al -
      I am happy with this as long as it is optional. There may be interesting cases
      where this flexibility is required. Please submit a proposal or a writeup on this.

        Issue Links

          Activity

          Hide
          dpitfiel added a comment -

          I agree this should be optional. More generally, shouldn't a repository be free
          to reject registration of node types that violate repository-specific
          constraints by throwing InvalidNodeTypeDefinitionException? (In other words,
          does this case warrant a new repository descriptor?)

          Show
          dpitfiel added a comment - I agree this should be optional. More generally, shouldn't a repository be free to reject registration of node types that violate repository-specific constraints by throwing InvalidNodeTypeDefinitionException? (In other words, does this case warrant a new repository descriptor?)
          Hide
          tripod added a comment -

          maybe i worked with/for jackrabbit, too much. it was always clear for me, that
          multiple-propdefs is the way how it should be. i wonder how many other
          repositories support this. i assume, that all db based repos can't do. i can see
          that the 'multiple' attribute is somewhat different than the others, since it
          does not really need a change in the table-schema. but if a repo can do
          residual, why can't it do multi-prop-defs ?

          however, i will writeup the respective section.

          Show
          tripod added a comment - maybe i worked with/for jackrabbit, too much. it was always clear for me, that multiple-propdefs is the way how it should be. i wonder how many other repositories support this. i assume, that all db based repos can't do. i can see that the 'multiple' attribute is somewhat different than the others, since it does not really need a change in the table-schema. but if a repo can do residual, why can't it do multi-prop-defs ? however, i will writeup the respective section.
          Hide
          abrown43 added a comment -

          It may be wise to call highlight this case with a descriptor rather than have it
          one of the unspoken optional aspects of JCR. JCR vendors must be able to throw
          an exception if the property definition violates some underlying constraints
          including conflicting definitions.

          Tobi, it is not about the storage of the content that may match multiple
          property definitions. There are at least three ways to do so with varying
          levels of efficiency. The concern is around efficiently providing search and
          typed operators on those fields (greater than on ints, like for strings, etc)
          and the expressibility of typing.

          I think this is an interesting idea and I am interested in the use cases around
          this.

          Show
          abrown43 added a comment - It may be wise to call highlight this case with a descriptor rather than have it one of the unspoken optional aspects of JCR. JCR vendors must be able to throw an exception if the property definition violates some underlying constraints including conflicting definitions. Tobi, it is not about the storage of the content that may match multiple property definitions. There are at least three ways to do so with varying levels of efficiency. The concern is around efficiently providing search and typed operators on those fields (greater than on ints, like for strings, etc) and the expressibility of typing. I think this is an interesting idea and I am interested in the use cases around this.
          Hide
          stefan_guggisberg added a comment -

          > I agree this should be optional. More generally, shouldn't a repository be free
          > to reject registration of node types that violate repository-specific
          > constraints by throwing InvalidNodeTypeDefinitionException? (In other words,
          > does this case warrant a new repository descriptor?)

          i agree with david that this should be optional and that it doesn't warrant
          a new repository descriptor.

          Show
          stefan_guggisberg added a comment - > I agree this should be optional. More generally, shouldn't a repository be free > to reject registration of node types that violate repository-specific > constraints by throwing InvalidNodeTypeDefinitionException? (In other words, > does this case warrant a new repository descriptor?) i agree with david that this should be optional and that it doesn't warrant a new repository descriptor.
          Hide
          Peeter Piegaze added a comment -

          Currently an implementation is free to reject any node type assignment on
          per-node-creation basis:

          <spec>
          Session.save()
          ...
          A ConstraintViolationException will be thrown if any of the changes to be
          persisted would violate a node type restriction. Additionally, a repository may
          use this exception to enforce implementation- or configuration-dependant
          restrictions.
          </spec>

          As for restrictions at node type registration time, the spec does not explictly
          mention the situation where a particular node type definition is un-registerable
          within a particular implementation. But, I think language to this effect should
          be added.

          This change, together with the general constraint violation proviso mentioned
          above, should be enough to address this issue. No new descriptor is needed.

          I have scheduled this issue for RC4

          Cheers,
          Peeter

          Show
          Peeter Piegaze added a comment - Currently an implementation is free to reject any node type assignment on per-node-creation basis: <spec> Session.save() ... A ConstraintViolationException will be thrown if any of the changes to be persisted would violate a node type restriction. Additionally, a repository may use this exception to enforce implementation- or configuration-dependant restrictions. </spec> As for restrictions at node type registration time, the spec does not explictly mention the situation where a particular node type definition is un-registerable within a particular implementation. But, I think language to this effect should be added. This change, together with the general constraint violation proviso mentioned above, should be enough to address this issue. No new descriptor is needed. I have scheduled this issue for RC4 Cheers, Peeter
          Hide
          Peeter Piegaze added a comment -

          change owner

          Show
          Peeter Piegaze added a comment - change owner
          Hide
          Peeter Piegaze added a comment -

          Fixed for RC4

          Show
          Peeter Piegaze added a comment - Fixed for RC4

            People

            • Assignee:
              Peeter Piegaze
              Reporter:
              abrown43
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: