Should it be optional to support "getDescendants" with an arbitrary "depth"?

XMLWordPrintable

    • Type: Bug
    • Resolution: Fixed
    • Priority: Minor
    • None
    • Affects Version/s: None
    • Component/s: Domain Model
    • None
    • Hide

      1) Add a NEW method to the Navigation Service called "getFolderTree" – This method will be functionally identical to calling getDescendants(depth=-1; type=Folder)

      • Open question: We can choose to expose a "folderId" parameter, in which case it's really "getFolderSubtree", or we can say that there's no folder param and it always returns the folder tree starting at the root folder. (I prefer the latter approach but could go either way).
      • Open question: Should this method ALSO be optional? (I'd prefer it it's required... but we should see if some repositories can't support this).

      2) We will add a NEW repository-optional capability (in section 2.1.1) as follows:

      • Name: capabilityDescendantNavigation
      • Type: Boolean

      If false, then the repository will throw the notSupported exception if the caller attempts to invoke the getDescendants method.

      ------------

      In the ATOMPub binding, the services doc should be updated to expose this capability (as a link).

      Show
      1) Add a NEW method to the Navigation Service called "getFolderTree" – This method will be functionally identical to calling getDescendants(depth=-1; type=Folder) Open question: We can choose to expose a "folderId" parameter, in which case it's really "getFolderSubtree", or we can say that there's no folder param and it always returns the folder tree starting at the root folder. (I prefer the latter approach but could go either way). Open question: Should this method ALSO be optional? (I'd prefer it it's required... but we should see if some repositories can't support this). 2) We will add a NEW repository-optional capability (in section 2.1.1) as follows: Name: capabilityDescendantNavigation Type: Boolean If false, then the repository will throw the notSupported exception if the caller attempts to invoke the getDescendants method. ------------ In the ATOMPub binding, the services doc should be updated to expose this capability (as a link).

      The current definition of the "getDescendants" method can take in 3 values for the "depth" parameter:

      • 1: Which behaves like GetChildren
      • -1: Which gets ALL descendants, regardless of depth
      • [2..n]: Which gets ONLY decendants up to the depth level specified.

      But I'm not sure that many repositories can handle the [2..n] case very efficiently. (E.g. in SharePoint the native data tables make this query non-trivial to execute, even though the "-1" and "1" cases are very efficient.)

      Should we provide a way for repositories to say that they don't support getting an arbitrary depth of children? Or maybe just remove that case, by saying that getChilren is ALWAYS with a depth of "-1" (i.e. remove the parameter entirely?)

            Assignee:
            Al Brown (Inactive)
            Reporter:
            Ethan Gur-esh (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: