10

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?

punkish
  • 13,598
  • 26
  • 66
  • 101
  • Good question! Right now I'm using GUIDs generated like described in [here](https://stackoverflow.com/questions/105034/create-guid-uuid-in-javascript). Depending on the implementation of the random number generator this might be a good practice... – Phonolog Dec 06 '16 at 10:08
  • 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 – punkish Dec 06 '16 at 10:21

1 Answers1

2

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:

Alen Siljak
  • 2,482
  • 2
  • 24
  • 29
  • 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. – Michael Jun 29 '20 at 00:52