FWIW, we scratched our head over the same problem, gave up, and wrote our own _id generator. It's a glorified timestamp with a big random seed after milliseconds part, formatted to be read by humans and look reasonable in urls. Since the high-order part increases with time, it shards well. We found it much easier to simply check for a unique index violation error on insert and retry with a new key whenever that happens than to solve the problem you're trying to solve.
But if you do come up with a good solution I'd love to see it :) -g On Tuesday, May 28, 2013 6:10:37 AM UTC-7, ryandesign wrote: > > 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.
