You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Nicholas Orr <ni...@zxgen.net> on 2009/07/29 05:33:50 UTC
Unique human readable ID
I get the whole point of letting couchdb generate id's.
At the same time I need a way to create a human
memorable/readable/communicative id:
- ID: 45060, 45061, 45062, etc
That is a whole lot simpler to relay over a phone call compared to:
- 1d98d82f5b6a628527344ba991cb7e2f
What have people done to satisfy the users of their systems with a simple id
and also be able to replicate the documents between different couchdb
instances?
I've come up with 2 ideas:
# 1
Have a single couchdb that has 50 documents (tickets) (figure out a way to
always have 50 available) in it like what is mentioned in the wiki to do
transactions[1]
#2
For each instance of the application prefix the id with it's instance id so
1.45060 & 2.45060 have the same id but were created on different instances.
Therefore when the two instances of the couchdb's replicate with each other
there are two unique id's
I can see this adding a fair amount of overhead if it gets to the point of
more then a few instances...
If I drop the requirement of replication everything becomes simple. Then I
have to wonder - why am I using CouchDB then??
Nick
[1] - http://wiki.apache.org/couchdb/Frequently_asked_questions#transactions
Re: Unique human readable ID
Posted by Brian Candler <B....@pobox.com>.
On Wed, Jul 29, 2009 at 01:33:50PM +1000, Nicholas Orr wrote:
> I get the whole point of letting couchdb generate id's.
> At the same time I need a way to create a human
> memorable/readable/communicative id:
> - ID: 45060, 45061, 45062, etc
> That is a whole lot simpler to relay over a phone call compared to:
> - 1d98d82f5b6a628527344ba991cb7e2f
#3. You could do what Git does: let people give the first few characters of
the ID, which is normally unique, and ask for more if needed.
N = 6
while (there are 2 or more docs in the DB with this N char prefix)
N += 2;
display first N characters of ID followed by ".."
Re: Unique human readable ID
Posted by Matt Aimonetti <ma...@gmail.com>.
>
> If I drop the requirement of replication everything becomes simple. Then I
> have to wonder - why am I using CouchDB then??
>
load balancing, backup, http api, caching, schemaless and probably many
other reasons ;)
I usually generate slugs when I need to use easy doc ids. You can add a
timestamp to your slugs, prepend them by your node id, verify their
uniqueness in your local DB etc...
It works great for me.
- Matt
On Tue, Jul 28, 2009 at 8:33 PM, Nicholas Orr <ni...@zxgen.net>wrote:
> I get the whole point of letting couchdb generate id's.
> At the same time I need a way to create a human
> memorable/readable/communicative id:
> - ID: 45060, 45061, 45062, etc
> That is a whole lot simpler to relay over a phone call compared to:
> - 1d98d82f5b6a628527344ba991cb7e2f
>
> What have people done to satisfy the users of their systems with a simple
> id
> and also be able to replicate the documents between different couchdb
> instances?
>
> I've come up with 2 ideas:
>
> # 1
> Have a single couchdb that has 50 documents (tickets) (figure out a way to
> always have 50 available) in it like what is mentioned in the wiki to do
> transactions[1]
>
> #2
> For each instance of the application prefix the id with it's instance id so
> 1.45060 & 2.45060 have the same id but were created on different instances.
> Therefore when the two instances of the couchdb's replicate with each other
> there are two unique id's
> I can see this adding a fair amount of overhead if it gets to the point of
> more then a few instances...
>
> If I drop the requirement of replication everything becomes simple. Then I
> have to wonder - why am I using CouchDB then??
>
> Nick
>
>
> [1] -
> http://wiki.apache.org/couchdb/Frequently_asked_questions#transactions
>
Re: Unique human readable ID
Posted by Adam Wolff <aw...@gmail.com>.
We are handling this by generating 128 bit random numbers (same amount of
data in a UUID) and then mapping them to 22 character strings, where the
first two characters are hex and the next 20 are base 64 (using
uppercase+lowercase+10 digits+"_"+"-" = 64 possible characters.)So 2^4 + 2^4
+ 20 * 2^6 = 128 bits
These could be trivially converted back to UUIDs.
Not a lot better than 36 character UUIDs, but a little.
A
On Tue, Jul 28, 2009 at 8:33 PM, Nicholas Orr <ni...@zxgen.net>wrote:
> I get the whole point of letting couchdb generate id's.
> At the same time I need a way to create a human
> memorable/readable/communicative id:
> - ID: 45060, 45061, 45062, etc
> That is a whole lot simpler to relay over a phone call compared to:
> - 1d98d82f5b6a628527344ba991cb7e2f
>
> What have people done to satisfy the users of their systems with a simple
> id
> and also be able to replicate the documents between different couchdb
> instances?
>
> I've come up with 2 ideas:
>
> # 1
> Have a single couchdb that has 50 documents (tickets) (figure out a way to
> always have 50 available) in it like what is mentioned in the wiki to do
> transactions[1]
>
> #2
> For each instance of the application prefix the id with it's instance id so
> 1.45060 & 2.45060 have the same id but were created on different instances.
> Therefore when the two instances of the couchdb's replicate with each other
> there are two unique id's
> I can see this adding a fair amount of overhead if it gets to the point of
> more then a few instances...
>
> If I drop the requirement of replication everything becomes simple. Then I
> have to wonder - why am I using CouchDB then??
>
> Nick
>
>
> [1] -
> http://wiki.apache.org/couchdb/Frequently_asked_questions#transactions
>