Problem: installed deployments are likely to contain documents whose for which index keys are too long to index. MongoDB 2.6 will be stricter about long index keys than earlier versions.

Proposal: the 2.6 release could include a command that looked for overly long index keys in a collection, and, depending on a boolean argument, either counted the number of bad documents, or else wrote each document to a BSON file in the dbpath and removed the document from the collection.

Rationale for setting aside offending documents in the mongod: suppose the collection only has an index on _id, then uniqueness of _id values isn't enforced, and so there may not be any unique value that identifies a document with overly long _id fields. So just reporting the bad documents will not be enough for a client program to issue valid cleanup operations in all cases.

Rationale for a boolean argument saying whether to count or set aside the documents: (a) users might want to assess the magnitude of the problem before clearing out the offending documents, and probably wants to do that assessment on secondaries but a command that changes collections has to be run on a primary.

Documentation changes needed: once this command exists, it needs to be documented, and the release notes/upgrade steps should recommend using this command to look for and/or clean out offending documents as part of the upgrade process (e.g., upgrade one secondary (per shard), then run this command).