list_indexes returns compound keys in a Map, which makes it impossible to reason about the order of the keys

[stiang]

I might be misunderstanding something here, but I’m trying to use list_indexes to get a list of current indexes, so that I can programmatically create any indexes that are missing, but it doesn’t seem possible to do this in a robust way since compound keys are returned as a Map, which doesn’t keep track of the order of the keys.

For example, I get this:

%{"key" => %{"Created" => -1, "ReportType" => -1}, "name" => "ReportType_-1_Created_-1", "v" => 2}

... for an index that was created with the following command:

%{
  createIndexes: "coll",
  indexes: [
    %{
      key: [{"ReportType", -1}, {"Created", -1}],
      name: "ReportType_-1_Created_-1"
    }
  ]
}

So this compound key was created with ReportType first, then Created, which matters greatly in terms of performance for our use case. But there’s no way to determine the actual ordering in the compound index based on the map I get back from list_indexes.

It seems my only option at the moment is to use the name field to deduce which order was used, but that requires a certain fixed naming scheme to work, which I unfortunately can’t rely on.

Is my assessment correct here, and if so, would it be possible to fix this somehow? It might not be feasible to change the format of the data returned from list_indexes (for compatibility reasons), but perhaps an additional function could be added that returns a keyword list instead?

[ankhers]

This is rather unfortunate. But this is the format that mongo actually gives us when we ask for the indexes. Javascripts Map object remembers the order the values were inserted, Elixir has no such guarantee. The best thing we could do is like you said, instead of returning a Map we should return a keyword list here.

This is something that would need to be looked into because we would not always want to return a keyword list instead of a map for everything.

[stiang]

Thanks for the reply. I’m not able to read the source code well enough to figure out how "deep" we would have to make a change to be able to preserve the order. It looks like list_indexes just returns an aggregation cursor without any special treatment, so we would presumably need to (at least) return something that is not an aggregation cursor (perhaps a special type of cursor)?

I realize that this is a hassle to solve and that listing indexes may not be considered core functionality, but on the other hand list_indexes is currently broken for at least some use cases, so it might be worth doing anyway. If changing the output from list_indexes is too drastic, perhaps something like list_ordered_indexes could be added?

Any thoughts on whether this is something you’ll be able to prioritize? Unfortunately the Elixir code in this repo looks a little too complicated for me to be able offer any direct coding help, but I’d be happy to contribute in other ways if I can.