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

Better handling of unique and sparse index constraints #172

Closed
wants to merge 5 commits into from

Conversation

johnnyshields
Copy link
Member

  • :sparse is now always set (no harm in setting it, in theory speeds up some edge cases where _slugs is unset on a large number of records)
  • :unique is now always set EXCEPT for an edge case related to paranoid docs. Previously we were not setting unique when by_model_type was true, however, I cannot think of any reason not to set it in this case.

- :sparse is always set (no harm in setting it, in theory speeds up some edge cases where _slugs is unset on a large number of records)
- :unique is always set EXCEPT for an edge case related to paranoid docs. Previously we were not setting unique when by_model_type was true, however, I cannot think of a good reason not to set it in this case.
@johnnyshields
Copy link
Member Author

Don't merge until question in #137 is answered

@digitalplaywright
Copy link
Collaborator

@johnnyshields Let me know when this is ready for your review.

- Correct unique/sparse index logic
@digitalplaywright
Copy link
Collaborator

@johnnyshields What is the status of this pull request? I don't want to let these changes fall by the wayside.

@johnnyshields
Copy link
Member Author

@digitalplaywright please give me a day or two to get back to you. Will take care of it.

@digitalplaywright
Copy link
Collaborator

@johnnyshields Sounds good. Thanks. :)

@johnnyshields
Copy link
Member Author

@digitalplaywright apologies this is still on my todo-list. Will get to it soon hopefully.

@digitalplaywright
Copy link
Collaborator

No worries. I hope to have this work in the next release. However, the current version is quite stable so there is no urgency.—
Sent from Mailbox

On Sun, Aug 24, 2014 at 1:43 AM, Johnny Shields notifications@github.com
wrote:

@digitalplaywright apologies this is still on my todo-list. Will get to it soon hopefully.

Reply to this email directly or view it on GitHub:
#172 (comment)

@johnnyshields
Copy link
Member Author

@digitalplaywright apologies I've been lagging on this issue. Actually I've been busying scaling my own app and I've learned a lot about how MongoDB indexes work recently (some of it the hard way 😓 ). So will apply the lessons to this soon.

@digitalplaywright
Copy link
Collaborator

No worries. I have been extremely busy as well so I can empathize.

@digitalplaywright
Copy link
Collaborator

@johnnyshields I am thinking that a new release is overdue so I might make one without this change. Since we have not settled on a clearly better indexing approach it is probably better to not defer the release for that. Please let me know what you think.

@johnnyshields
Copy link
Member Author

@digitalplaywright totally fine to release without this. I still need to sit down and think through this PR, I haven't gotten there yet. Apologies for leaving this out in the open so long.

@dblock
Copy link
Collaborator

dblock commented Sep 21, 2015

Hey @johnnyshields - what should we do about this one?

@dblock
Copy link
Collaborator

dblock commented Sep 8, 2016

@johnnyshields Want to clean this up/close it?

@dblock
Copy link
Collaborator

dblock commented Sep 8, 2016

Trying to finish this in #227.

@johnnyshields
Copy link
Member Author

@dblock will close in favor of your PR

@dblock
Copy link
Collaborator

dblock commented Sep 9, 2016

Yup, #227 was merged.

@dblock
Copy link
Collaborator

dblock commented Sep 11, 2016

FYI was released in 5.3.0

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

Successfully merging this pull request may close these issues.

3 participants