Because it seems like a good idea to *know* that an ID is unique, without having to possibly generate multiple IDs and query the database server in a loop to find one that happens to be unique.
Another module I found, cuid, explains it this way: > Because of the nature of this problem, it's possible to build an app from the > ground up and scale it to a million users before this problem rears its head. > By the time you notice the problem (when your peak hour use requires dozens > of ids to be created per ms), if your db doesn't have unique constraints on > the id because you thought your guids were safe, you're in a world of hurt. > Your users start to see data that doesn't belong to them because the db just > returns the first ID match it finds. > > Alternatively, you've played it safe and you only let your database create > ids. Writes only happen on a master database, and load is spread out over > read replicas. But with this kind of strain, you have to start scaling your > database writes horizontally, too, and suddenly your application starts to > crawl (if the db is smart enough to guarantee unique ids between write > hosts), or you start getting id collisions between different db hosts, so > your write hosts don't agree about which ids represent which data. https://github.com/dilvie/cuid Mongodb objectids already have the same characteristics as cuids -- a timestamp; a machine id; a process id; and a counter with randomness: http://docs.mongodb.org/manual/reference/object-id/ Since mongodb objectids contain a machine id they can be generated on multiple database servers without collisions so they don't suffer from the same constraints the author of cuid was talking about above. And I don't at this time need the ability to create such IDs from the client; it's sufficient to me that they be created by the database server. So again, the question is not "how do I generate short IDs that might not be unique that will cause me problems when they aren't". The question is "how do I take the unique IDs that my database has generated and automatically transform them so that I can keep the original ID in the database but use the transformed value in routes, views, etc. with a minimum of fuss." On May 28, 2013, at 07:20, Alan Hoffmeister wrote: > Why not generate a small ammount of letters and numbers and check it's > existence agains the database? If nothing is found you just got a > unique small "hash" and you can save it in any field of the document. > -- > Att, > Alan Hoffmeister > > > 2013/5/28 Ryan Schmidt: >> I'm using mongodb with mongoose, and using normal mongodb objectids as my >> primary key. I like objectids but in URLs they're a bit long, and I'd like >> to use something shorter. >> >> I've seen modules like shortid which generate shorter strings, but I'm not >> convinced of their uniqueness. I am convinced of the uniqueness of objectids >> and would like to find a way to just compress them down a bit. Then I found >> the module hashids, which is able to do just that. >> >> Now the question is: how do I best incorporate hashids into my models? Do I >> somehow override each model's id property so that it's automatically >> converted into a hashid right after reading from the database and converted >> back to an objectid right before saving? Or do I make a virtual field "myid" >> or something? How have others handled this? -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
