Sequential unique IDs for PouchDB

Question

PouchDB best-practice recommendation is to use PUT instead of POST for creating a new document (analogous to a row in an rdbms) primarily because the latter generates a random ID that makes it inefficient for subsequent sorting of the data. PUT, on the other hand, requires providing a user-generated, unique ID.

I am a bit puzzled that PouchDB doesn't seem to provide this functionality out-of-the-box. So, what is the best way to generate a unique, sequential ID (analogous to PostgreSQL's sequence)? I could use something analogous to maxID, but the main issue, in my view, is to ensure no one else inserts a record between when I determine the maxID and when I actually succeed in inserting a record.

Suggestions?

Antony

Good question! Right now I'm using GUIDs generated like described in here. Depending on the implementation of the random number generator this might be a good practice... – Meghannmegiddo

well, I am not sure what the point is of using GUIDs since you can always get those by using POST as I mentioned above. The key is to have something unique yet predictable and sortable to accommodate PouchDB. The best would be something that imitates Postgres's sequence – Antony

Answer 1

While I don't have the complete answer, a suggestion would be to try something like Twitter's Snowflake ID. If there is a JavaScript implementation, this might be an option.

A simpler version would be to simply use

var id = (new Date()).getTime();

which returns the number of milliseconds since 1 January 1970 00:00:00 UTC.

Edit: the following article suggests a couple of Node packages:

• uuid
• flake-idgen

Ornithosis

all the examples I see in the documentation mention using the time, yet obviously it's possible at some point for two clients to generate a timestamp during the same millisecond. UUIDs seem to be a lot of overhead when e.g. you're using it to generate an id for eacj element in a document, while snowflake ids seem limited at arbitrary partition boundaries: e.g. what if you have more than 32 clients, or 32 processes on a client? Overall this seems to be not just a hard problem, but an impossible one to solve efficiently in a distributed environment. – Accordant