mongoid-slug icon indicating copy to clipboard operation
mongoid-slug copied to clipboard

Sparse option breaks db:mongoid:create_indexes on existing collections

Open glebtv opened this issue 11 years ago • 13 comments
trafficstars

"Index with name: _slugs_1 already exists with different options"

glebtv avatar Apr 19 '14 11:04 glebtv

Maybe it should be configurable?

glebtv avatar Apr 19 '14 11:04 glebtv

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.

digitalplaywright avatar Apr 20 '14 17:04 digitalplaywright

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.

digitalplaywright avatar May 17 '14 03:05 digitalplaywright

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.

glebtv avatar May 22 '14 21:05 glebtv

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 avatar May 22 '14 21:05 glebtv

@glebtv I think you are referring to unique, not sparse here. Sparse does not enforce any kind of validation.

johnnyshields avatar Jul 10 '14 19:07 johnnyshields

Ignore the above, I see the issue here.

johnnyshields avatar Jul 10 '14 23:07 johnnyshields

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.

dbackeus avatar May 21 '15 12:05 dbackeus

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

manxingxing avatar Jun 29 '15 15:06 manxingxing

Bump @manxingxing @glebtv What do we want to do about this?

dblock avatar Sep 22 '15 15:09 dblock

@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.)

johnnyshields avatar Sep 22 '15 15:09 johnnyshields

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

johnnyshields avatar Sep 22 '15 15:09 johnnyshields

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.

johnnyshields avatar Oct 12 '16 08:10 johnnyshields