Skip to content

#1071: fix BQ system tests under Py3k #1074

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

Merged
merged 2 commits into from
Aug 19, 2015
Merged

#1071: fix BQ system tests under Py3k #1074

merged 2 commits into from
Aug 19, 2015

Conversation

tseaver
Copy link
Contributor

@tseaver tseaver commented Aug 19, 2015

See #1071.

Prevents TypeError in 'writerow()' on Py3k.

Fixes #1071.
Avoids blowing up the cleanup code, stranding the bucket.
@tseaver tseaver added type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. api: bigquery Issues related to the BigQuery API. labels Aug 19, 2015
@tseaver
Copy link
Contributor Author

tseaver commented Aug 19, 2015

@dhermes PTAL.

@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Aug 19, 2015
@dhermes
Copy link
Contributor

dhermes commented Aug 19, 2015

Makes me think we should also have tearDown keep going if a delete fails. (Better yet would be just to leave blobs out of it and call bucket.delete(force=True), though then it can't inter-mix with the delete-able BigQuery objects.)

@dhermes
Copy link
Contributor

dhermes commented Aug 19, 2015

@tseaver Running system tests now on local machine. Should be done soon.

@tseaver
Copy link
Contributor Author

tseaver commented Aug 19, 2015

We could make to_delete a list of callables, and use functools.partial to curry in the force=True bit for buckets.

@tseaver
Copy link
Contributor Author

tseaver commented Aug 19, 2015

BTW, do you have access to clean up the stranded buckets on the Travis project's console?

@dhermes
Copy link
Contributor

dhermes commented Aug 19, 2015

Yes I do. Just deleted the 2 most recent from test failures

@dhermes
Copy link
Contributor

dhermes commented Aug 19, 2015

LGTM. System tests all passing.

dhermes added a commit that referenced this pull request Aug 19, 2015
@dhermes dhermes merged commit c2370a8 into googleapis:master Aug 19, 2015
@tseaver tseaver deleted the 1071-bigquery-system_tests_py3k branch August 19, 2015 14:20
parthea pushed a commit that referenced this pull request Oct 21, 2023
)](GoogleCloudPlatform/python-docs-samples#1074)

The use of base64 is essentially an implementation detail of the Cloud KMS REST
API: it is required only so that arbitrary binary data can be included in a JSON
string, which only allows Unicode characters. Therefore, the "encrypt" sample
function should decode the base64-encoded ciphertext before writing the
file. Similarly, "decrypt" should not assume that an input file is
base64-encoded, but should perform the base64-encoding itself before sending the
encrypted data to KMS.

This aligns with how the "gcloud kms encrypt" and "gcloud kms decrypt" commands
behave. See https://stackoverflow.com/q/45699472 for an example of user
confusion caused by the mismatch.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: bigquery Issues related to the BigQuery API. cla: yes This human has signed the Contributor License Agreement. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants