-
Notifications
You must be signed in to change notification settings - Fork 189
Fix issue of queries not reaching completed state #210
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
2e07453
to
b99fd96
Compare
@@ -317,7 +317,7 @@ def _get_server_version_info(self, connection: Connection) -> Any: | |||
query = "SELECT version()" | |||
try: | |||
res = connection.execute(sql.text(query)) | |||
version = res.scalar() | |||
version = res.scalar_one() |
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.
Could you add a test?
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.
It seems that 351
behaves differently with query state ..
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.
cc: @arhimondr @losipiuk Is there consensus on whether the new behaviour is working as expected? I think this is related to trinodb/trino#13055
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 should be a non-op change as the only difference between scalar
and scalar_one
is that scalar_one
would additionally throw if no rows are returned.
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.
SELECT version() should always return exactly one row and we want to raise exception when it doesn't.
Alternative solution might be to execute res.fetchall()
after version = res.scalar()
but it's cumbersome.
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 issue is not limited to sqlalchemy. Following dbapi code will also result in cancelled query while the result is scalar.
cur.execute('SELECT VERSION()')
cur.fetchone()
cur.cancel()
It is indeed related to the PR on Trino that @hashhar refers to. The issue is that the python client doesn't acknowledge the reception of the data by calling the next_uri on the Trino API.
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.
ca8add6
to
2f3493a
Compare
2f3493a
to
f431230
Compare
f431230
to
4c3a9f6
Compare
8467ba7
to
323c15f
Compare
This code can be used to simulate this using dbapi on the #220 branch. This didn't result in any unfinished queries. Now again I don't know enough about the related Trino internals what's the chance of this becoming a flaky test on github CI.
In other words we need to be sure that doing 2 fetchone() calls (actually fetching up to 3 requests as long next_uri is not null) is enough to fully consume all results and mark the query as finished. |
323c15f
to
5cf68f4
Compare
This has been addressed via #220 now. It has a different test though since the test here is potentially flaky (and also fails some of the existing tests regarding INSERTs). |
Fix issue of queries not reaching completed state - see discussion on https://trinodb.slack.com/archives/CGB0QHWSW/p1658934510749439
Adds a test to demonstrate effect of trinodb/trino#13055