Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-56233

Multi-key for wildcard indexes have special encoding that must be extended to clustered indexes

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.0.0-rc0
    • Component/s: None
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Execution Team 2021-05-17, Execution Team 2021-05-31

      Description

      Wildcard indexes may have many (an unbounded number of) multi-key paths, one multi-key path for every path to an array in any document.

      e.g. something like
      {_id: <>, a: [40, 30]} => "a" (multi-key path)
      {_id: <>, a: {b: [40, 30]}} => "a.b" (multi-key path)

      Rather than storing the multi-key path in the mdb catalog entry for the index, the multi-key paths for wildcard indexes are stored in the index table, as a KeyString. There is a reserved range of record IDs for multi-key paths, and a special RecordID constant is used in the KeyString (which is the 'key' with the record ID appended at the end).

      However, clustered indexes use RecordID strings as opposed to int64 for regular indexes. There is an expectation in the WiredTigerIndex layer such that an overall index has a KeyFormat of either string or int64, and it checks for that type. Therefore, we run into problems with a clustered wildcard index specially handling multi-key with an int64, and then the lower code layer expects a string.

      Furthermore, clustered indexes strings were designed to support many different types, wherein timestamps is just one among many. We need to figure out how to either reserve a safe range of RecordIDs for string RecordID multi-key path documents; or otherwise flag a KeyString as a wildcard multi-key path entry.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              louis.williams Louis Williams
              Reporter:
              dianna.hohensee Dianna Hohensee
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: