On Fri, Feb 27, 2009 at 9:00 AM, Damien Katz <[email protected]> wrote: > The doc ids can be generated client side, so clients can use any scheme you > want. For how the server generates UUIDs, there has been some talk about > doing some work there, but I don't think anyone has started it. > > -Damien > > > On Feb 27, 2009, at 7:44 AM, Wout Mertens wrote: > >> On Feb 26, 2009, at 8:18 PM, Damien Katz wrote: >>> >>> Also, he Ids don't need to be sequential (1,2,3,4...), just ordered >>> (1,5,19,22...). And they don't need to sort higher or lower than all the >>> other ids, so long as they are clustered together. The each btree nodes >>> that have to be loaded that isn't in cache is expensive. The more the keys >>> have to be inserted into random places in the btree, the worse the caching >>> behavior. Right now, with the crypto random UUIDs we generate, it's >>> basically the worst case scenario for doc inserts. >> >> So why not decrease security by a tunable factor and add a random number >> to the previous UUID instead? >> >> And while we're on the subject, I've wished for automatic doc UUIDs that >> nonetheless have a fixed prefix. More human readable plus it doubles as a >> type field... Any chance of that or is that one of the beginner mistakes? >> >> Wout. > >
There was talk of switching the internal uuid generationg to a version 1 style instead of the version 4 (random) style. My suggestion was to make the _uuids endpoint accept a v=[1|4] url parameter to choose with a config file default but people seemed to not like that idea. HTH, Paul Davis
