mongoid-slug
mongoid-slug copied to clipboard
Sparse option breaks db:mongoid:create_indexes on existing collections
"Index with name: _slugs_1 already exists with different options"
Maybe it should be configurable?
Is it possible for you to recreate the index? The reason for the change in the index is described here: https://github.com/digitalplaywright/mongoid-slug/pull/155.
Any updates on this issue? I would like to make sure we have reasonable migration paths from one version to another, and this was an unfortunate mistake in our previous indexing scheme.
No, I just pinned mongoid-slug to the old version. Recreating all indexes is not really an option for a large dataset with many collections, since in practice it should be done manually, and since indexes already exist for me, all my records already have slugs so I don't need sparse.
But yes, I completely agree that for new projects sparse index is a good idea, that's why I think it should be configurable and default to false in current patch version and to true in next minor/major version, if done according to semantic versioning.
@glebtv I think you are referring to unique, not sparse here. Sparse does not enforce any kind of validation.
Ignore the above, I see the issue here.
Since _slugs attribute seems to default to an empty array we get the duplicate key error as soon as we create our second record. Sparse will only work if _slugs was not set to begin with if I'm not mistaken.
I'm not sure how anyone can use this gem and have a working setup. Has there been a change in the uniqueness handling in new mongodb versions, did it use to accept multiple documents having empty arrays?
We're using the gem from scratch on a new app so we have no legacy data to worry about.
Encounters the same problem as @dbackeus .
Steps to reproduce:
class Article
include Mongoid::Document
include Mongoid::Slug
include Mongoid::Paranoia
field :url_seg, type: String
slug :url_seg
end
Article.create_indexes
Article.create
Article.create
# => E11000 duplicate key error index
Find out a ticket on mongoDB's site: https://jira.mongodb.org/browse/SERVER-3934
Bump @manxingxing @glebtv What do we want to do about this?
@glebtv all you need to do is drop the index which is affected, then recreate specifically that index. (You can do this for a single index without affecting all other indexes.)
Alternatively, you could do the following steps without affecting production:
- Create a duplicate index to your existing one but with a different name: e.g "_slugs_1_copy" (Mongo doesn't allow renaming indexes: https://jira.mongodb.org/browse/SERVER-7337)
- Drop your existing "_slugs_1" index
- Create the new "_slugs_1" index
- Drop the "_slugs_1_copy" index
I think a suitable workaround would be to have an index: false option on the slug that doesn't create the default index. If so, the user is responsible for defining their own.