Database transaction current value is null while it shouldn't

[Felix Halim]

Consider the following code:

var testRef = database.ref('/test');

testRef.set('bla').then(function () {

  testRef.transaction(function (currentValue) {

    console.log('currentValue: ', currentValue);

    return 'bli';

  });

});

It first prints:

currentValue:  null

Then it prints:

currentValue:  bla

Why it prints null the first time?

The code intentionally wait until "bla" is set before starting the transaction.

Felix Halim

[Jacob Wenger]

Hey Felix,

This is actually expected behavior. The Firebase SDKs will optimistically try null in transactions if it doesn't know what the actual value is (that is, if there is no local listener for the node at which the transaction is occurring). If the value at that node is indeed null, the transaction will go through. If the value is not null, the server will tell the client SDK what the actual value of the node is and tell it to retry the transaction with that value. That is why you need to write your transaction code in a way that handles the function being run any number of times.

Cheers,

Jacob

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAAbwPorFigkTLS9kSK5y-ubAj-ZmCJv3F2mqwUbSbW_phwRGRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Felix Halim]

IIUC, Firebase tries to use the latest value to supply the current value for the transaction, is that right?

In your case, if there is a local listener, then it most likely knows what is the current value and uses that.

Firebase may be can optimize further by caching previous values in a Promise chain?

So the earlier promises that sets a value to a ref, should be used if later that value is updated again in a transaction in the next promise.

FYI, I am using it in a firebase functions that is unlikely to have any on() listener set (since functions are short lived).

Maybe it is a good idea to cache values set in a function and use it as the current value in a transaction?

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAGcMwsAFW%3DoDjBSwjmqjrE9%2BaqusJvKfZQyNUPmumr58ti2Bew%40mail.gmail.com.

[Jacob Wenger]

Your understanding is mostly correct. Firebase will use the latest value to supply the current value for the transaction. If there are no local listeners, it will "guess" null the first time the transaction is sent to the server. If a local listener exists, it will just use that value.

Firebase will not always cache the value in a Promise chain. If you just use a once(), we will clear the cache after it is successful (as far as I'm aware). The only way to keep the value cached is via an on() listener (again, as far as I'm aware).

Functions is a bit special since although the Functions environment and firebase-functions SDK know what the current value actually is (the function got called with that value after all), the regular Firebase SDK (in this case, it's the Admin Node.js SDK) uses a different cache and does not know the value. And given that this is a relatively new feature, there is no way to prime the cache for the Admin Node.js SDK unless you actually create a listener. However, you are better of just having the transaction guess null initially and handle that case in your transaction function.

Does that makes sense? It's a bit hard to explain this concept so apologies if I am still not making sense. If you still have questions, I can try to explain it a different way or get someone else who understands it even better than I do to answer it.

Jacob

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAAbwPoqnZBbmjJuQheLW22Yy1OQYDR3vW4j-N9tRK856zQiQ2w%40mail.gmail.com.