-
-
Notifications
You must be signed in to change notification settings - Fork 108
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
let "unique: true" ensure mongo index? #36
Comments
The docs say to combine it with ensureIndex, but I'm not sure I want to force that. If anyone else reading this has an opinion, feel free to weigh in. |
Unfortunately, I don't have experience to weigh in. Maybe it could be optional by setting something like "unique: true" vs. "unique: index". |
If the current implementation is rather something like a pre-check for duplicates, |
The main purpose was to be able to display client-side errors about uniqueness, so yes mostly a pre-check. Will consider. |
Eric, strictly from a performance standpoint, pre-checking unique requires you to issue a query/fetch to check length and verify unique or not unique, correct? On the client that seems OK, I don't care about spending cycles on MiniMongo. On the server, though, it seems like it would make a lot of sense to use _ensureIndex and let Mongo determine the uniqueness constraint and throw exceptions as needed. Maybe this is what you're already doing? I'm just envisioning a scenario where I might be importing 10,000 records from an external data system and poor Collection2 doubling the cost of effort to do so. Granted if speed was a real concern then one would use _collection.insert instead. I like testbird's idea of a true | false | 'index' selection and if it's 'index' then let Collection2 handle the indexes. I think if I'm declaring schemas and calling out "uniqueness" it's a good way to avoid forgetting to apply unique constraints at the DB level. 2c. |
@caseylutz, good points. I think it does full finds on the server right now, so yes could be expensive. I never really intended that to be the final way it would work. An ideal situation would be if the Meteor folks add unique indexes to minimongo, and then we could try to find some way to tap into that error message to display the reactive simple-schema messages, etc. Regarding true/false/'index', I guess what I'm trying to ponder is whether there are cases in which one would want I'm leaning toward calling _ensureIndex automatically when |
I totally agree. I like the simplicity of just having Out of curiosity, if you go with the _ensureIndex route, do you think you will still be able to capture and bubble up validation-error messages if they occur on the server via autoForms, or would that end up being an edge case where the user may potentially not see any visible feedback for a failure? |
I think I would keep the The point about soft constraints is valid, but those could be achieved with custom validation. There's a pending enhancement to allow a separate "warning" schema for an autoform, and that would be another solution. |
Yep that's definitely true. That problem you mention right there is one of the head-scratchers I've had going with the whole Meteor (as well as, to some extent, Collection2/AutoForm) validation scheme... There seems to be an assumption that clients are being handed lots of data about the universe and are generally self-sufficient in terms of validation and such. However, I find in my most of my applications clients are privvy to only a very small selection of data but their validations are heavily dependent on data they're not privileged to see. Easiest example is picking a "username". I don't want users being published the usernames for every user on the site to validate, upon submit, whether or not that username is already taken ( |
Hy there, happy new year! A reason not to want an index can be performance with high write loads. To avoid an index one would have to use another pattern involving findAndModify or an optimistic loop, but for this you simply don't specify "unique:true" on the collection, and implemnt/use that other pattern instead. So I think having unique:true ensure an index seems ok. Concerning server side validation, one usefull pattern I think could be to use isSimulation to let (only) the clients add some extra "unconfirmed: true" field locally, and that then gets overwritten (deleted) again after the operation succceeded on the server and the confirmed document is propagated. |
For user accounts, you may be able to make the relevant subset of input fields work similar to a search box (sending the changed text to the server every something ms), but only turning red if the search gets an exact hit (instead of displaying selections). By now, maybe it is ok starting to base such a search on a mongo text index (instead of implementing own indexing) |
just saw this mentioned (without testing/checking implementation):
|
Hey all, check out the referenced PR by @mquandalle. I think it's a pretty robust solution to indexing. The explanation in the readme is here: Any concerns? |
I should add a note that if a field has both |
Right. I saw that in the code, but I didn't realize the readme section doesn't mention it. Should be updated. |
Good separation of index and unique, thumbs up! |
Very nice; very elegant solution. |
The |
Meteors _ensureIndex could be used until the stable API comes along.
http://stackoverflow.com/questions/11392566/mongo-geospatial-index-and-meteor
The text was updated successfully, but these errors were encountered: