Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FR: Transaction Set/Create document issue #257

Closed
romanmen opened this issue Apr 9, 2018 · 4 comments
Closed

FR: Transaction Set/Create document issue #257

romanmen opened this issue Apr 9, 2018 · 4 comments

Comments

@romanmen
Copy link

romanmen commented Apr 9, 2018

Hi,

My project is uses in node js code that using firebase-admin package.
According to business logic of my project I need use in transaction set mechanism of firestore but I can't receive the WriteResult of firestore like in the regular (non transaction) set.
Regular Set returns Promise with Write Time value.

I needs same value from firestore by transaction.set.

Can some one help me how can I receive it ? Maybe my approach isn't correct and you will be able help with another approach.

Node JS Code Sample:

transactionSetDocument(id, docContent)
{
return this.db.runTransaction(transaction =>
{
let docRef = this.db.collection('MyCollection').doc(${id});
transaction.set(docRef, docContent, { merge: true });
//set document doesn't return the Promise with WriteResult, so how can I obtain this data
}
}

Thanks,
Roman

@hiranya911
Copy link
Contributor

What exactly are you trying to do? It is not normal to access the write result of a transaction from within the same transaction. This is not usually available since the transaction commits all writes at the end in one atomic operation.

@romanmen
Copy link
Author

I want to measure the real time (without network issues) of writing documents to firestore, because I need the firestore's real time of written document. The clock on my machine is different from firestore's clock, so I need measure according to firestore's time.
Basically, my business logic requires to achieve the storage/update of 1000 documents per second to same collection. It should be performed one by one and by transaction because in case of failure by any reason we must try to store the problem document again. Firestore has a batch mechanism for bulk of documents but it is unsuitable for the scalability and recovery of our servers.

@hiranya911
Copy link
Contributor

@schmidt-sebastian for more information.

I do not believe it is possible to access the result of an individual write within the same transaction. Transactions are atomic, and the enclosing writes are not saved to the remote database until the whole transaction is committed. So the intermediate state of a transaction is not accessible without violating the atomicity and isolation properties of Firestore. It may be possible to get the commit time of the entire transaction. Does that satisfy your requirement?

It is still not clear why you would want to access the write time in this manner. Just use batch writes if that's important. The commit() method there returns an array of WriteResult objects. Batch writes are indeed scalable than trying to write one document at a time, and recovery is simpler due to their atomic nature (if an error occurs, just retry the whole batch).

@schmidt-sebastian
Copy link
Contributor

As Hiranya pointed out, Firestore transactions commit all writes only after you exit the transaction callback. No write takes place when you call transaction.set. We commit the transaction automatically when your function returns, and make sure that none of the documents you read as part of your transaction were modified in the meantime.

If you need to access the WriteTime of a document that was written via a transaction, you can fetch it the document via DocumentReference.get(). The update time in the snapshot corresponds to the write time in your transaction.

You can also use FieldValue.serverTimestamp() to encode this same value in your document.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants