Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sparse option breaks db:mongoid:create_indexes on existing collections #160

Open
glebtv opened this issue Apr 19, 2014 · 13 comments
Open

Sparse option breaks db:mongoid:create_indexes on existing collections #160

glebtv opened this issue Apr 19, 2014 · 13 comments
Labels

Comments

@glebtv
Copy link

glebtv commented Apr 19, 2014

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

@glebtv
Copy link
Author

glebtv commented Apr 19, 2014

Maybe it should be configurable?

@digitalplaywright
Copy link
Collaborator

Is it possible for you to recreate the index? The reason for the change in the index is described here: #155.

@digitalplaywright
Copy link
Collaborator

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.

@glebtv
Copy link
Author

glebtv commented May 22, 2014

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
Copy link
Author

glebtv commented May 22, 2014

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.

@johnnyshields
Copy link
Member

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

@johnnyshields
Copy link
Member

Ignore the above, I see the issue here.

@dbackeus
Copy link

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.

@manxingxing
Copy link

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

@dblock dblock added the bug? label Sep 22, 2015
@dblock
Copy link
Collaborator

dblock commented Sep 22, 2015

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

@johnnyshields
Copy link
Member

@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
Copy link
Member

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants