-
Notifications
You must be signed in to change notification settings - Fork 32
test: fix string compliance tests #23
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The literal string overrides LGTM, just some nits on the docstrings.
The cleanup override I'm not sure about as mentioned in #20. Let's resolve the discussion there and then apply any decision we make to this PR 👍
The
|
The |
The Github Action says it's already passing against the emulator 👍 |
test/test_suite.py
Outdated
|
||
The original test string is : \"""some 'text' hey "hi there" that's text\""" | ||
|
||
Spanner doesn't support string which contains `'s` in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is incorrect. Spanner does support strings containing `'s': https://cloud.google.com/spanner/docs/lexical#literals
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using the original test string with the Python client:
Input: """some 'text' hey "hi there" that's text"""
Output: 'some \'text\' hey "hi there" that\'s text'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, python successfully convert that string but spanner throws an error like 400 Syntax error: Expected \")\" or \",\" but got string literal \'text\' [at 1:41]\nINSERT INTO t_string (x) VALUES (\'some \'\'text\'\' hey \"hi there\" that\'\'s text\')\n
.
I have tried with DBAPI with the direct string 'some \'text\' hey "hi there" that\'s text'
and it throws the same error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spanner prod is working with these 3 strings and adding escape characters to them.
$ Report(name=r"1. backslash one \ backslash \\ two end").save()
$ Report.objects.all()[0].name
'1. backslash one \\ backslash \\\\ two end'
$ Report(name=r"2. backslash one \ backslash \ two end").save()
$ Report.objects.all()[1].name
'2. backslash one \ backslash \\ two end'
$ Report(name="""3. some 'text' hey "hi there" that's text""").save()
$ Report.objects.all()[2].name
'3. some 'text' hey "hi there" that's text'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean when it comes through the DB API it throws an error:
from google.cloud.spanner_dbapi import connect
connection = connect('instance-id', 'databse-id')
cursor = connection.cursor()
cursor.execute("INSERT INTO t (x) VALUES ('backslash one \ backslash \\ two end')") #it will through an error `400 Syntax error: Illegal escape sequence`
cursor.execute("""INSERT INTO t (x) VALUES (some 'text' hey "hi there" that's text)""") #it will through an error `400 Syntax error: Expected \")\" or \",\" but got string literal \'text\' `
@vi3k6i5 if you are using spanner client directly for the insert, then for help can you share the actual sql query syntax passing at that time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, it looks like the issue is the SQL query rather than the data string. Spanner supports both 'backslash one \ backslash \\ two end''
and "some 'text' hey "hi there" that's text'
however, when specifying these types of strings by SQL, the additional escapes are necessary.
Rather than skipping these tests, we need to add additional logic to add these additional escapes before they are used to generate SQL statements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is the DBAPI code showing the strings are supported:
connection = connect('test-instance', 'test-db')
cursor = connection.cursor()
cursor.execute(
"INSERT INTO t (pkey, val) VALUES (0, \"{}\")".format(
r'backslash one \\ backslash two \\\\ end'))
cursor.execute(
"INSERT INTO t (pkey, val) VALUES (1, \"{}\")".format(
r"""some 'text' hey \"hi there\" that's text"""))
cursor.execute("SELECT * FROM T")
for row in cursor.fetchall():
print(str(row[1]))
Output:
some 'text' hey "hi there" that's text
backslash one \ backslash two \\ end
…n-spanner-sqlalchemy into fix_string_compliance_tests
…n-spanner-sqlalchemy into fix_string_compliance_tests
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
…n-spanner-sqlalchemy into fix_string_compliance_tests
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
…n-spanner-sqlalchemy into fix_string_compliance_tests
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
@larkee Can you change the |
…n-spanner-sqlalchemy into fix_string_compliance_tests
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
test/test_suite.py
Outdated
|
||
|
||
class StringTest(_StringTest): | ||
def test_literal_backslashes(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the added render_literal_value
method, test_literal_backslashes
and test_literal_quoting
should no longer need to be overridden. Please remove.
""" | ||
raw = ["\\", "'", '"', "\n", "\t", "\r"] | ||
if type(value) == str and any(single in value for single in raw): | ||
value = '"{}"'.format(value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Locally, after removed the test_literal_backslashes
and test_literal_quoting
overrides, I was still getting failures.
The following change fixes the errors:
value = '"{}"'.format(value) | |
value = 'r"""{}"""'.format(value) |
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
No description provided.