16

I am currently using firestore for a small application. I am trying to see what I can use for auto increment ids. A simple use case which is common is order nos. A human consumable identifier I dont want to use the document id. This is not consumable for humans.

gopal
  • 335
  • 1
  • 4
  • 11
  • Don't go for custom ids, which can be problematic for future scalability. instead of going incremental document id you can go for a incremental field inside document. for more you can check here https://link.medium.com/JBLoRkvgz3 – BHAR4T Jan 26 '20 at 16:54
  • As a side note, auto-incrementing IDs are problematic due to **hotspotting** - getting too many requests to a specific part of the database. **This can happen with any kind of incrementing ID in Firestore** (e.g., "doc1", "doc2", and so on). These are called "monotonically increasing document IDs". Hotspotting incurs latency and in the worst case timeouts or conflicts. In short, you should only be using random IDs, which is your first line of defense against hotspotting. Best practice is to allow Firestore to create the IDs with push or its "create ID" methods. – uɥƃnɐʌuop Feb 28 '21 at 21:46

1 Answers1

14

There is no built-in auto-increment operator in Firestore. If you want something like that, you will have to build it yourself.

This typically involves keeping track of the latest ID you've used in a document in a well-known location, and then reading-and-updating that document from the client in a transaction.

But do seriously consider whether you can't use Firestore's built-in identifiers, as there are many reasons why Firestore comes with those built-in instead of having an auto-increment operator.

I highly recommend checking out some of these related questions:

And this page in the Firestore documentation in distributed counters.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • 1
    Thank you. I see most of the solutions recommending push ids. But If I give push id as a confirmation no to the user. The problem is usability. If they call operations it will be difficult for both of them to repeat the push ids. example pushid JhQ7APk0UtyRTFO9-TS seems tough for a user to repeat on phone to operations. – gopal Mar 09 '19 at 22:27
  • 2
    Consider using a code that only has to be unique for the user, which reduces the complexity considerably. Then consider either using a simpler scheme for the IDs e.g. based on date/time, as a single user is unlikely to ever place multiple orders at the same time from multiple devices. If those don't work, you can take the transaction approach that I described in the top of my answer. I'd just consider that a last resort myself. – Frank van Puffelen Mar 10 '19 at 04:12
  • 1
    Unfortunately the lack of "unique field" constraints in Firestore makes random IDs impractical: the ID is the only field of the document guaranteed to be unique. – forresthopkinsa Aug 09 '21 at 05:14