Why not simply use base56 encoding of the object id?
On Tue, May 28, 2013 at 10:37 PM, George Snelling <[email protected]>wrote: > 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/<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. > > > -- -- 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.
