Uploaded image for project: 'Jackrabbit Oak'
  1. Jackrabbit Oak
  2. OAK-50 Implement User Management
  3. OAK-482

Group members stored in a rep:members tree

    XMLWordPrintableJSON

    Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.12
    • Component/s: core
    • Labels:
      None

      Description

      storing group members in a dedicated rep:members tree is currently not
      yet implemented.

      • jr 2.x node type definition allows SNS which are not supported in oak
      • jr 2.x node type definition stores members in residual properties, which
        up to now doesn't allow to use a specific property index.
      • the jr 2.x implementation is rather cumbersome as it doesn't allow
        to change the configuration later on such that existing groups can
        benefit from the config change.
      • the node names in the tree structure would rely on userId being equal
        to the principal name, which is not mandated.

      for a new implementation in oak i see the following variants to provide this
      feature:

      variant 1:
      • drop SNS
      • change member-property to a multivalue rep:members property in the
        node hierarchy -> same index as for non-tree implementation
      • config change will result in the member-tree to be created also for
        existing groups.
      • even if member-tree option is enabled the members are stored in the
        default mv property and just have a tree structured added if required
        based on the config option.
      • adjust xml import of user content accordingly

      pros:

      • dedicated property index for rep:members property defined by rep:Members
        works out of the box -> performance of membership lookup.
      • fixing SNS definition
      • fixing confusion of uid with principalname

      cons:

      • not backwards compatible out of the box
      • updating membership might not be efficient
      • we need to add backwards compatible behavior when reading and querying
        existing membership information or provide an upgrade path that converts
        'old' structure to the new one upon repo upgrade
      variant 2:
      • rebuild use same logic as in JR2.x to build tree structure but include
        fixing the principalName/uid issue.

      pros:

      • backwards compatible (no upgrade path required)
      • most probably changing membership of a group was more efficient

      cons:

      • efficient lookup of membership doesn't work (AFAIK the property index is limited
        to named properties). thus we probably need to adjust the query/index logic such that
        a property index can be created for residual properties defined by the rep:Members node type
      • SNS problem not addressed -> might cause failure upon upgrade

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                tripod Tobias Bocanegra
                Reporter:
                angela Angela Schreiber
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 168h
                  168h
                  Remaining:
                  Remaining Estimate - 168h
                  168h
                  Logged:
                  Time Spent - Not Specified
                  Not Specified