Firebase transaction api call current data is null

Question

When I use transaction() to update a location, data at that location is returning null even though the location having some da

Answer 1

You need to follow this pattern:

var pinRef = firebase.database().ref('vm-pin-generator');
pinRef.transaction(function(oldPin) {
    // Check if the result is NOT NULL:
    if (oldPin != null) {
        return localPinIncrementor(oldPin);
    } else {
        // Return a value that is totally different 
        // from what is saved on the server at this address:
        return 0;
    }
}, function(error, committed, snapshot) {
    if (error) {
        console.log("error in transaction");
    } else if (!committed) {
        console.log("transaction not committed");
    } else {
        console.log("Transaction Committed");
    }
}, true);

Firebase usually returns a null value while retrieving a key for the first time but while saving it checks if the new value is similar to older value or not. If not, firebase will run the whole process again, and this time the correct value is returned by the server.

Adding a null check and returning a totally unexpected value (0 in this case) will make firebase run the cycle again.

Answer 2

Simply showing an example implementation to elaborate on @Kato accepted answer above with a custom upsert function:

  /**
   * Transactional insert or update record
   * @param  {String} type - object type (table or index) to build lookup path
   * @param  {String} id - object ID that will be concat with path for lookup
   * @param  {Object} data - new object (or partial with just edited fields)
   * @return {Object}       new version of object
   */
  const upsert = (type, id, data) => {
    return new Promise((resolve, reject) => {
      if (!type) {
        log.error('Missing db object type')
        reject(new TypeError('Missing db object type'))
      }
      if (!id) {
        log.error('Missing db object id')
        reject(new TypeError('Missing db object id'))
      }
      if (!data) {
        log.error('Missing db data')
        reject(new TypeError('Missing db data'))
      }

      // build path to resource
      const path = `${type}/${id}`
      log.debug(`Upserting record '${path}' to database`)

      try {
        const ref = service.ref(path)
        ref.transaction(record => {
          if (record === null) {
            log.debug(`Creating new record`) // TODO: change to debug
            return data
          } else if (record) {
            log.debug(`Updating existing record`) // TODO: change to debug
            const updatedRecord = Object.assign({}, record, data)
            return updatedRecord
          } else {
            return record
          }
        }, (error, committed, snapshot) => {
          if (error) {
            log.error(`Error upserting record in database`)
            log.error(error.message)
            reject(error)
          } else if (committed) {
            log.debug(`Saved update`)
          } else {
            log.debug(`Record unchanged`)
          }

          if (snapshot) {
            resolve(snapshot.val())
          } else {
            log.info(`No snapshot found in transaction so returning original data object`)
            resolve(data)
          }
        })
      } catch (error) {
        log.error(error)
        reject(error)
      }
    })
  }

Answer 3

Transactions work in the manner of Amazon's SimpleDB or a sharded cluster of databases. That is to say, they are "eventually consistent" rather than guaranteed consistent.

So when you are using transactions, the processing function may get called more than once with a local value (in some cases null if it's never been retrieved) and then again with the synced value (whatever is on the server).

Example:

pathRef.transaction(function(curValue) {

    // this part is eventually consistent and may be called several times

}, function(error, committed, ss) {

    // this part is guaranteed consistent and will match the final value set

});

This is really the mindset with which you must approach transaction anyways. You should always expect multiple calls, since the first transaction may collide with another change and be rejected. You can't use a transaction's processing method to fetch the server value (although you could read it out of the success callback).

Preventing the locally triggered event

When the transaction happens, a local event is triggered before it reaches the server for latency compensation. If the transaction fails, then the local event will be reverted (a change or remove event is triggered).

You can use the applyLocally property on transactions to override this behavior, which makes the local results slower but ensures that only the server value is triggered locally.

pathRef.transaction(function(curValue) {

    // this is still called multiple times

}, function(error, committed, ss) {

    // this part is guaranteed consistent and will match the final value set

}, 
    // by providing a third argument of `true`, no local event
    // is generated with the locally cached value.
true);