couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: utc_random (COUCHDB-465)
Date Thu, 10 Sep 2009 13:18:55 GMT

No. The time in microseconds comes from the erlang:now/0 call which is
guaranteed to be monotonically increasing in side a single VM. The
randomness only comes into play during replication to avoid

As to JS compatibility, i thought the monotonically increasing
guarantee would be better. You can still convert that number to
microsceconds and shift to get milliseconds. Also, less bits means
less random.

Paul Davis

On Thu, Sep 10, 2009 at 7:32 AM, Brian Candler<> wrote:
> Just a minor comment/query about the recently committed utc_random
> algorithm.
> ;   utc_random - Time since Jan 1, 1970 UTC with microseconds
> ;     First 14 characters are the time in hex. Last 18 are random.
> Presumably if you do a bulk insert, and multiple documents happen to get
> inserted in the same microsecond, they will appear in an apparently random
> order when you retrieve them by doc_id?
> I wonder if it wouldn't be better to have an incrementing sequence for the
> right-hand part. This can be reset to a new random value whenever the time
> part changes.
> In that case you could probably get away with having the time accurate to
> the millisecond, rather than microsecond. This would have the advantage of
> being compatible with Javascript's time functions, and would give more
> randomness on the right-hand side.
> I could have a look at doing this if anyone thinks it's worthwhile.
> Regards,
> Brian.

View raw message