[SERVER-21888] Provide operation to determine if an index exists Created: 13/Dec/15  Updated: 14/Apr/16  Resolved: 14/Mar/16

Status: Closed
Project: Core Server
Component/s: Index Maintenance
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor - P4
Reporter: Eric Stobbart Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-18518 Add filter support for listIndexes Backlog
Related
is related to SERVER-15754 Allow createIndexes to take "key" fie... Closed
Sprint: Query 11 (03/14/16)
Participants:

 Description   

I'm currently using the python driver.
I keep a list of indexes per collection in memory using the IndexModel object.
Before starting any operation, I'd like to check that my indexes are in place.

I'd like to be able to ask the server if my indexes exist per collection. Or have `getIndexes` return a stable document that I can compare against.

Discussion started @github with the following pull request..

https://github.com/mongodb/mongo-python-driver/pull/299



 Comments   
Comment by Max Hirschhorn [ 14/Mar/16 ]

Closing as a duplicate of SERVER-18518.

Comment by Max Hirschhorn [ 05/Mar/16 ]

You can't currently take the index document provided by listIndexes and use it to create an index.

Sure you can. It just has to be on a database and collection with the same name as what is specified in the "ns" field.

> db.mycoll.drop();
> db.mycoll.createIndex({a: 1});
> var res = db.runCommand({listIndexes: 'mycoll'});
> var indexes = new DBCommandCursor(db.getMongo(), res).toArray();
> printjson(indexes);
[
  {
    "v" : 1,
    "key" : {
      "_id" : 1
    },
    "name" : "_id_",
    "ns" : "test.mycoll"
  },
  {
    "v" : 1,
    "key" : {
      "a" : 1
    },
    "name" : "a_1",
    "ns" : "test.mycoll"
  }
]
> db.mycoll.drop();
> db.runCommand({createIndexes: 'mycoll', indexes: indexes});
{
  "createdCollectionAutomatically" : true,
  "numIndexesBefore" : 1,
  "note" : "index already exists",
  "numIndexesAfter" : 2,
  "ok" : 1
}
> db.runCommand({createIndexes: 'othercoll', indexes: indexes});
{
  "spec" : {
    "v" : 1,
    "key" : {
      "_id" : 1
    },
    "name" : "_id_",
    "ns" : "test.mycoll"
  },
  "ok" : 0,
  "errmsg" : "namespace mismatch"
}

One solution to this ticket might be to add the ability to query for an index document (by name, key, etc.). That used to be possible when indexes where defined in system.indexes, but no longer with the listIndexes command. A query option for listIndexes might do the trick.

This has already been requested in SERVER-18518, so if that's the functionality you're really looking for, then I'm inclined to close this ticket as a duplicate.

My thoughts on some of the discussion in the pull request

Determining whether two createIndexes requests are the same seems like a different question than whether those two requests will create the same indexes. The definition of whether index A is equivalent to index B seems dependent on the use-case. For instance,

skipped_keys = ["v", "ns", "background", "name"]

seems problematic to me where an application wants to ensure that their usages of db.mycoll.find({}).hint(<index_name>) are valid. I'd be concerned about a driver attempting to define what it means for one index to be equivalent to another.

I think a better idea would be to open a ticket against the server requesting a stable index document format that can be passed unaltered to the createIndexes command.

The results of the "listIndexes" command are stable in the sense that there won't be breaking changes to the contents of the "infoObj" because indexes created on older versions of MongoDB should be usable on newer versions of MongoDB. When new index options are added (e.g. storageEngine in 3.0 and partialFilterExpression in 3.2), then these options will become additional properties that the "listIndexes" command returns as part of the information regarding the index.

Comment by Eric Stobbart [ 14/Dec/15 ]

Thanks guys. Just for some context on what I'm during currently, I only check the keys and direction. I'm not concerned with the name generated or if it was created in the background. I'm just making sure that the indexes exist on any database I'm working with. Also an issue I ran into was that the read's were allowed on secondaries, even though the primary hadn't completed the index and replicated yet. My index manager now goes through all the nodes, gets an index list per collection and compares. If an index was missing I'd also check the currentOp to see if it was being created and it's progress.

Comment by Bernie Hackett [ 14/Dec/15 ]

No worries, I think your idea is correct.

Comment by Sam Kleinman (Inactive) [ 14/Dec/15 ]

behackett sorry for the confusion.

I'm going to retitle this issue to "provide operation to determine if index exists", and make this a feature request.

Please let me know if I'm mischaracterizing the issue here.

Comment by Bernie Hackett [ 14/Dec/15 ]

One solution to this ticket might be to add the ability to query for an index document (by name, key, etc.). That used to be possible when indexes where defined in system.indexes, but no longer with the listIndexes command. A query option for listIndexes might do the trick.

Generated at Thu Feb 08 03:58:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.