Unique indexes on existing collections
Currently, CosmosDB requires unique indexes to be created before inserting data in an empty collection. MongoRestore creates indexes after importing data, which is incompatible with CosmosDB's flow, and forces the user to create unique indexes manually in order to import data. This is impractical for those who require daily imports on several collections. CosmosDB should be able to import data using MongoRestore's flow, by allowing unique indexes to be created after inserting data.
After reviewing we will be moving this to unplanned and will put on our backlog.
Is there any update now?
I'm still facing the same problem and not able to migrate my database.
What can I do now? Seems I should not use the cosmos DB for mongo.
This is our scenario:
When we do schema changes we need to be able to update a large number of document in a collection. For example we could be adding/removing fields or renaming fields. If one of those fields are used in an index on the collection, then the migration will fail. All of our migrations like this use dropIndexes() in order to drop indexes before starting the migration but that command always fails because the collection isn't empty - and Cosmos DB doesn't allow indexes to be created or dropped unless the collection is empty.
This also means that we can't rebuild the index after the migration either.
Right now I don't know of any good workaround for this either, which makes using Cosmos DB a big headache.
I propose that you add support for creating / dropping indexes on collections that are no empty.