-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Find a better name for Row.commit_modifications() or fold the behavior into #1548
Comments
@jonparrott @jgeewax @tseaver I'd love to have you all chime in. |
I like the first option, but unsure about complexity/edge cases. For option two, would |
I like the first also. |
What does the user expect the state-of-the-world to be after |
I think the best way forward is to actually create This way No issues with complexity, just worried that people would be confused. Here's some code snippets for how things work right now >>> row1 = table.row(b'row-key')
>>> row2 = table.row(b'row-key', filter_=filter_)
>>>
>>> row1.set_cell(u'fam', b'col', b'val')
>>> row2.set_cell(u'fam', b'col', b'val')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "gcloud/bigtable/row.py", line 166, in set_cell
self._get_mutations(state).append(mutation_pb)
File "gcloud/bigtable/row.py", line 97, in _get_mutations
raise ValueError('A filter is set on the current row, but no '
ValueError: A filter is set on the current row, but no state given for the mutation
>>>
>>> # Use state
>>> row1.set_cell(u'fam', b'col', b'val', state=True)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "gcloud/bigtable/row.py", line 166, in set_cell
self._get_mutations(state).append(mutation_pb)
File "gcloud/bigtable/row.py", line 102, in _get_mutations
raise ValueError('No filter was set on the current row, but a '
ValueError: No filter was set on the current row, but a state was given for the mutation
>>> row2.set_cell(u'fam', b'col', b'val', state=True)
>>>
>>> # state also an argument in delete(), delete_cell(), delete_cells()
>>>
>>> row1.append_cell_value(u'fam', b'col', b'extra-bytes')
>>> row2.append_cell_value(u'fam', b'col', b'extra-bytes')
>>>
>>> row1.increment_cell_value(u'fam', b'col', 123)
>>> row2.increment_cell_value(u'fam', b'col', 123) |
@tseaver Having a hard time answering your question. Can you give a scenario of what you have in mind? |
If
That seems pretty natural: the user can't get the row into a state where uncommitted changes remain after a call to |
Yup. Will implement and send out for PR. |
See discussion in #1547 for context.
The name
modifications
is intended to map to the RPC method nameReadModifyWriteRow
but the word modification is a synonym of mutation, so this method is poorly named. The method actually sends changes thatso we should either
Row.commit()
ascommit(append_only=True)
Row.commit_cell_updates
(or a better name than that)The text was updated successfully, but these errors were encountered: