IDs sequenced by time?

Hi there

I’m using uuid.v1() for keys within my LevelDB + node.js app. Whenever I list entries from the LevelDB, the sorting happens by these keys and unfortunately it is very random.

I mean, in a boring relational DB you increment the primary keys. Whenever you query the rows, the are sorted by these primary keys as a default behavior. This is good, you always know that recently inserted rows appear on top.

But with UUIDs v1 as keys, the sequence is pretty random.

Is there a solution for that? Do I need to fine-tune some options to achieve that behavior or can this be implemented at all in a new version?

[broofa]

@sm2017: Good question.

I edited my last comment to remove the four field form (the one that resulted in clockseq being the primary sort field). Readers should just stick to the replace(/^(.{8})-(.{4})-(.{4})/, '$3-$2-$1') form.

While an argument can be made for including clockseq in the sort order because it gets incremented if there’s a system clock regression, the fact it is randomly initialized on process startup makes it unsuitable for inclusion in sorting. (Including it in my previous comment was a mistake on my part. My apologies for the confusion.)

What this means is that in the (very rare?) case where the system clock regresses (goes back in time), the sort order won’t reflect the order in which ids were generated. I expect that’s a minor concern for most folks, however.

(Note: The behavior of clockseq described here is part of the 4122 spec, where the intent is to minimize the risk of uuid collisions.)

[broofa]

> var id = '110ec58a-a0f2-4ac4-8393-c866d813b8d1';
undefined
> id.replace(/^(.{8})-(.{4})-(.{4})/, '$3-$2-$1')
"4ac4-a0f2-110ec58a-8393-c866d813b8d1"

Dealing with non-standard id formats is a slippery slope to which there is no bottom. And since this can pretty easily be bolted on outside of this module I don’t see any particular reason to include it here. Sorry. 😕