2

Creating a document in Firestore can be done with .add() or with .set(). For this particular questions, let's assume that the document holds a property with its own docId.

Approach with .add() and a following .set() update:

db.collection("cities").add({
  docId: null,
  name: 'Tokyo',
  country: 'Japan'
});

//... get docId of inserted document via DocumentReference Promise return of add()

//update with docId
db.collection("cities").doc(docId).set(city, {merge: true});

Approach with only using set():

const newCityRef = db.collection('cities').doc();
// Later...
const res = await newCityRef.set({
  // ...
});

Is there any particular advantage of using .add() when I want to store a document that holds its own docId? Also, is there any particular disadvantage to always creating new documents with .set()?

When using the second approach, does .doc() always return an ID that's unique and unused? Using the first approach would always result in two write operations, while only using .set() requires only one.

Tobias Kaufmann
  • 625
  • 1
  • 5
  • 19
  • 3
    Does this answer your question? [Firestore: difference between set() and add()](https://stackoverflow.com/questions/47474522/firestore-difference-between-set-and-add) – hfontanez Feb 14 '21 at 21:11
  • 2
    Sorry but I don't know why this question has been marked as duplicate, only the heading is equal to the provided post. I am aware of the differences between the two methods, I just want to know what would be the best approach (or best practice) when storing the documentId in a field aswell. Also, this does not answer if .doc() always provides a unique ID? – Tobias Kaufmann Feb 15 '21 at 10:09
  • 1
    @hfontanez the question does not seem to be a duplicate the intent of the question and the precise question asked is definately distinct. have not checked for other duplicates, but it is definately not a duplicate of the mentioned question. – Fabian Schneider Feb 15 '21 at 16:04

1 Answers1

1

Is there any particular advantage of using .add() when I want to store a document that holds its own docId? Also, is there any particular disadvantage to always creating new documents with .set()?

I believe that you've already answered this part of your question with the following valid assessment you issued:

Using the first approach would always result in two write operations, while only using .set() requires only one.

Meaning that billing-wise the more writes you issue the more you'd be billed as you are billed depending on the location of the instance by the number of writes per 100,000 documents. Now, implementation-wise the following section of the docs reveals that there are no particular differences of the methods themselves behind the scenes:

Behind the scenes, .add(...) and .doc().set(...) are completely equivalent, so you can use whichever is more convenient.

So I believe that for your particular use case using the doc() set() approach could be the best approach (to avoid an increased in billing due to the number of writes).

When using the second approach, does .doc() always return an ID that's unique and unused?

Using .doc() will necessarily create an empty document with an automatically generated identifier that is unique as advised on the reference for the doc() method.

Daniel Ocando
  • 3,554
  • 2
  • 11
  • 19
  • Thanks a lot! Do you know if `.doc()` "reservers" the id for some time? Assuming I aim to create thousands of documents asynchronous in one process, would it be possible to get duplicates? I know it would be very unlikely due to its length etc., but I'm just wondering from a theoretical point of view. – Tobias Kaufmann Feb 19 '21 at 14:32
  • Hi Tobias, introducing the asynchronous nature of the issue I'm not sure if at some point the ids could collide. I don't believe this will be an issue, but haven't tested such a scenario in production though. – Daniel Ocando Feb 19 '21 at 16:22
  • 1
    According to the provided answer here: https://stackoverflow.com/questions/66282712/is-it-possible-to-receive-duplicate-ids-with-firebase-doc/66282767?noredirect=1#comment117184349_66282767 it seems to be almost impossible to get duplicates as the id is generated on the client side. – Tobias Kaufmann Feb 19 '21 at 18:30