Delete data on row.js mutation calls

[muraliQlogic]

Fixes #151 (it's a good idea to open an issue first for discussion)

• Tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

[codecov]

Codecov Report

Merging #207 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #207   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          10     10           
  Lines        1260   1266    +6     
=====================================
+ Hits         1260   1266    +6

Impacted Files	Coverage Δ
src/row.js	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e77c3c9...503d0fe. Read the comment docs.

[sduskis]

There are two cases where this.bigtable.request is called. Those cases also need to delete data.

[sduskis]

Also, 'create', 'delete', and 'save' methods all need the same logic.

[sduskis]

@theacodes, we have an object in row.js that's the result of a read from Cloud Bigtable, but also can perform additional mutations against the Cloud Bigtable service.

At this point, we either have to cleanup the read state when mutations are performed, or we have to design a different solution.

We're hoping to reach Beta soon, so we have to decide what to do ASAP.

[theacodes]

I lean on @JustinBeckwith and @kinwa91 along with the maintainers of this repo to pick what's idiomatic in Node.js

[sduskis]

@JustinBeckwith and @kinwa91 do you have any guidance about this PR?

[JustinBeckwith]

Apologies - I don't entirely understand the question. Can you elaborate?

[sduskis]

Issue #149 / #151 is caused by an "active record" idiom employed in row.js. A Row is both the result of a read, and a mechanism by which mutation RPCs are sent to Cloud Bigtable. We maintain a member variable (data) in Row, which is not updated when ever a mutation occurs.

We can fix this in the following ways, and we need to figure out which one is the best (idiomatic, and least painful for the user) approach :

1. Remove all state from Row, and provide a more primitive object to the user for the result of reads
2. Clear out Row's data whenever a mutation occurs
3. If data is set and a mutation occurs, update the data variable with the latest values.

We opted for option 2 in this PR, but one of the other options may be "better." We're looking for guidance on direction.

[stephenplusplus]

This is familiar to the metadata property on all of our "ServiceObject" instances, e.g. a GCS File:

bucket.getFiles(function(err, files) {
  files[0].metadata // metadata record
})

metadata is not meant to be guaranteed accurate as your app ticks on; only at the time of fetching. So, we expose a getMetadata() to allow the user to refresh it, if they need to. At the same time, the internal property metadata is updated.

I would advise a user that .data is only accurate at the time of a read. And if you can make the guarantee that it's accurate at the time of any mutation, even better (is it possible to do that without requiring a subsequent read?).

The issue in #151 is definitely a bug-- instead of extending the local cache of "data", can we just overwrite this.data?

[sduskis]

@stephenplusplus, it's not possible to keep .data up to date, since there are too many variables, including server-state and the filters used for reading the data.