Jackrabbit Oak
  1. Jackrabbit Oak
  2. OAK-583

Inconsistencies in property index definitions

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None

      Description

      while trying to simplify the property-index definitions and adding
      one for the access control content, i detected the following inconsistencies
      with the property "propertyNames":

      • the property is sometimes single valued (e.g. "uuid") and sometimes
        multivalued ("nodetypes")
        IMO the property name implies that it is multivalued. however, i get the
        impression that this doesn't work for unique property index definitions.
        (test failure)
      • the property is defined using Type.STRING (implicit) or Type.STRINGS.
        IMO however, Type.NAMES would be more appropriate.
      • while moving out the user related index, i used type name without noticing.
        i will change to STRING(S) such that we have it consistent (see above).

        Activity

        Hide
        Alex Parvulescu added a comment -

        I removed the fixme from the code, as the mentioned test failures are no longer there (rev r1446564)

        it's just about having it consistent.

        +0 I see what you are saying, but the benefit of forcing a type on this property is not so great in the end.
        Using an invalid property name would just render you index definition useless, but that's also the case with a typo in the definition and there's really no way to prevent that.

        Also, I see the fact that you can use both type string and type name for the definition as a feature

        Show
        Alex Parvulescu added a comment - I removed the fixme from the code, as the mentioned test failures are no longer there (rev r1446564) it's just about having it consistent. +0 I see what you are saying, but the benefit of forcing a type on this property is not so great in the end. Using an invalid property name would just render you index definition useless, but that's also the case with a typo in the definition and there's really no way to prevent that. Also, I see the fact that you can use both type string and type name for the definition as a feature
        Hide
        angela added a comment -

        i fixed the failures some time ago... it's just about having it consistent.

        Show
        angela added a comment - i fixed the failures some time ago... it's just about having it consistent.
        Hide
        Alex Parvulescu added a comment -

        IMO the property name implies that it is multivalued. however, i get the impression that this doesn't work for unique property index definitions. (test failure)

        I've removed the TODO from the IndexUtils, reran all the tests and nothing failed.
        Which tests are failing so I can take a look?

        Show
        Alex Parvulescu added a comment - IMO the property name implies that it is multivalued. however, i get the impression that this doesn't work for unique property index definitions. (test failure) I've removed the TODO from the IndexUtils, reran all the tests and nothing failed. Which tests are failing so I can take a look?

          People

          • Assignee:
            Alex Parvulescu
            Reporter:
            angela
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development