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
Pull Requests
Activity
Olivier just reminded me: https://issues.apache.org/jira/browse/CASSANDRA-10786
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?
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