Make ServerValue.increment() public #2852
Conversation
schmidt-sebastian
force-pushed
the
mrschmidt/publicincrement
branch
from
68bb79f to
84d3068
Compare
Binary Size ReportAffected SDKs
Test Logs |
| @@ -6920,6 +6920,15 @@ declare namespace firebase.database.ServerValue { | |||
| * ``` | |||
| */ | |||
| var TIMESTAMP: Object; | |||
|
|
|||
| /** | |||
| * Returns a placeholder value that can be used to atomically increment the | |||
There was a problem hiding this comment.
Consider the documentation from Firestore: https://googleapis.dev/nodejs/firestore/latest/FieldValue.html#.increment
There was a problem hiding this comment.
To the degree that we follow the same rules of course. We overflow to float instead.
There was a problem hiding this comment.
In the JS SDK itself, we don't do anything special though. Internally, we use floating point arithmetic (with its limited 2^53 precision) and once we round-trip through the server we gain land in JavaScript number land (please let me know if I am wrong here).
Firestore is a little different in that it can retain the actual value for 2^53 + 1 on the backend, whereas JavaScript cannot.
To me, it seems like the RTDB just uses JavaScript number semantics all throughout - is that correct? I can modify the comment to say that we are using floating point arithmetic throughout (similar to https://googleapis.dev/nodejs/firestore/latest/FieldValue.html#.increment), but I want to make sure that my understanding is correct.
There was a problem hiding this comment.
I guess it just makes a difference that whole numbers would be interpreted as ints in other SDKs whereas a fractional number will cause other SDKs to see floats. OTOH that isn't different from any other field, so it doesn't really matter.
|
@Feiyang1 I need someone else to approve this too. Can you take a look? |
As per API proposal: go/servervalue-increment-api