Moving Bigtable Row.commit_modifications() into commit().

[dhermes]

Fixes#1548.

[dhermes]

@jgeewax@jonparrott LMK what you guys think of this

[theacodes]

This seems pretty reasonable in terms of the API surface/usage.

[dhermes]

👍

[dhermes]

I think I should update bigtable-data-api.rst as well

[tseaver]

Now that I see the change, it feels like there should really be two different row classes in play, rather than having methods which are present, but only available based on the value of append.

[theacodes]

Now that I see the change, it feels like there should really be two different row classes in play, rather than having methods which are present, but only available based on the value of append.

I'm somewhat leaning towards this as well. Row seems to have significant variadic behavior based on one argument.

[dhermes]

Two classes or three? There are three distinct cases here. Also, do users want three?

The worst / grossest "variadic"-ness to me is in the output of commit().

[dhermes]

@tseaver@jonparrott Bump (want to get a release out ASAP so this PR can't block too long).

Two questions:

• Two or three row classes? (3 implicit types, "direct", "conditional" and "append")
• Would users blanch at having to use 3 separate classes? Could we sufficiently ease this pain with the Table.row() factory?

Also @jgeewax Please weigh in.

[tseaver]

Three classes, I think: the Table.row() factory could figure out which one to instantiate, based on the params passed?

[theacodes]

the Table.row() factory could figure out which one to instantiate, based on the params passed?

Agreed.

[dhermes]

Working on it now.

[dhermes]

This can definitely be dropped since #1557 and others covered it.