Utilize v2 protocol's ability to skip result set metadata for prepared statement execution

Description

In the v2 native protocol, a flag may be set which indicates that result set metadata (column names and types, etc) can be omitted. This flag can be used with prepared statements, where the metadata is returned along with the prepared statement ID.

Environment

None

Pull Requests

None

Activity

Show:
Adam Holmberg
August 22, 2016, 8:27 PM
Adam Holmberg
August 22, 2016, 7:27 PM
Edited

I'm starting to think this is not worth it. Even after PYTHON -621, there are issues with caching result metadata for prepared statements. Consider this scenario:

Here, we reprepare and update result metadata on the first statement, but the second one blows up when it is not rejected by the server, and the original metadata is used to decode the response. This is, of course, contrived, but you can imagine the other statement in another instance of the client.
We could mitigate this some by invalidating result metadata with schema change events, but there are still race conditions. We could also try some special exception handling + reprepare around decoding with cached results, but that adds complexity and still falls short in addressing another way this is broken:

Note the second result calling 'c' 'b'.

I like this as a concept for optimization, but I don't feel like it's totally robust at the moment. I propose to revert this and look into options. For example, it might be possible to include the result metadata in the query ID hash in addition to the keyspace + query string.

Thoughts?

Greg Bestland
July 14, 2016, 6:25 PM
Edited

Added test to validate result metadata across protocol versions here.

I'm working off the assumption that provided it's available the the result_metadata is used. That appears to be the case.
https://github.com/datastax/python-driver/commit/de8351c3968b338c07c392c94076df817d2908ff

Fixed

Assignee

Unassigned

Reporter

Tyler Hobbs

Fix versions

Labels