Skip to content
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

Implement multi-row mutations for python Bigtable #2411

Closed
destijl opened this issue Sep 23, 2016 · 8 comments
Closed

Implement multi-row mutations for python Bigtable #2411

destijl opened this issue Sep 23, 2016 · 8 comments
Assignees
Labels
api: bigtable Issues related to the Bigtable API. priority: p2 Moderately-important priority. Fix may not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@destijl
Copy link

destijl commented Sep 23, 2016

It would be great if you could add multi-row mutations to the Bigtable python client library. AFAICS it doesn't exist yet.

The RPC API supports it:
https://cloud.google.com/bigtable/docs/reference/data/rpc/google.bigtable.v2#mutaterowsrequest

It just isn't implemented for python. The first use case I ran into is I have a bunch of rows to delete and a want to make a single RPC to do that, but I'm sure there will be more.

@tseaver tseaver added type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. api: bigtable Issues related to the Bigtable API. labels Sep 23, 2016
@tseaver
Copy link
Contributor

tseaver commented Sep 23, 2016

See #1546.

@destijl
Copy link
Author

destijl commented Sep 23, 2016

Thanks, I'm not using happybase but the context manager approach suggested in that bug looks good.

@garye
Copy link
Contributor

garye commented Apr 3, 2017

Good news: @skyfox is currently working on implementing this

@CuriousDima
Copy link
Contributor

CuriousDima commented Apr 10, 2017

In my current solution, I added mutation class and the new multi rows mutation function as a method of the Table class.

Pros:

  1. Easy to use - mutations can be specified outside of rows;
  2. No need to construct Row instances. Original RPC call works on a level of row keys.

Cons:

  1. new abstraction
  2. The Row class should be refactored and work with mutations 3) Mutations for every row should be the same.

Alternative solution. Same new table method. In a method body - extract rows keys/mutations and build request.

Pros:

  1. No new abstractions

Cons:

  1. Extracting row key from row object
  2. Not so easy to use - Rows should be constructed first.

The second way, from my point of view, is closer to the current implementation and would prefer to extended Row class a little. Even with a small overhead for extracting keys from rows.

Any cons?

@garye
Copy link
Contributor

garye commented Apr 12, 2017

@tseaver , any thoughts on this?

@lukesneeringer lukesneeringer added the priority: p2 Moderately-important priority. Fix may not be included in next release. label Apr 12, 2017
@CuriousDima
Copy link
Contributor

CuriousDima commented May 11, 2017

Pull request: #3401

@mbrukman
Copy link
Contributor

@garye, @skyfox: since PR #3401 was merged, can we close this issue, or is there more work left?

@tseaver
Copy link
Contributor

tseaver commented Jul 26, 2017

AFAICT, the merge of #3401 should have closed this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: bigtable Issues related to the Bigtable API. priority: p2 Moderately-important priority. Fix may not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

8 participants