[
https://issues.apache.org/jira/browse/CASSANDRA-13992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16250786#comment-16250786
]
Kurt Greaves commented on CASSANDRA-13992:
------------------------------------------
My understanding is that, at the moment, {{METADATA_CHANGED}} will _always_ be
set for a conditional update, regardless of whether it's necessary or not.
Necessary being defined as the schema has actually changed and the prepared
statements need to be updated client side to reflect those schema changes.
[~omichallat] is this true? what exactly is "metadata" referring to on the
driver side, and why is the answer "always no" for conditional updates? If
there is a change to one of the columns in the update is that going to cause
problems if we don't tell the driver that it has changed?
I'm with Olivier that that's a hacky addition to the driver, but if it's not
even necessary as per above then simply only passing an empty digest will be
sufficient.
I've updated my
[branch|https://github.com/apache/cassandra/compare/trunk...kgreav:13992] to
reflect this. Note I've changed to using {{MD5Digest#compute}} to calculate an
"empty" digest. Although it's thread local it will always be the same digest,
and this will also solve the initial preparation problem, as it also uses the
{{EMPTY}} resultset + metadata.
> Don't send new_metadata_id for conditional updates
> --------------------------------------------------
>
> Key: CASSANDRA-13992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13992
> Project: Cassandra
> Issue Type: Bug
> Reporter: Olivier Michallat
> Assignee: Kurt Greaves
> Priority: Minor
>
> This is a follow-up to CASSANDRA-10786.
> Given the table
> {code}
> CREATE TABLE foo (k int PRIMARY KEY)
> {code}
> And the prepared statement
> {code}
> INSERT INTO foo (k) VALUES (?) IF NOT EXISTS
> {code}
> The result set metadata changes depending on the outcome of the update:
> * if the row didn't exist, there is only a single column \[applied] = true
> * if it did, the result contains \[applied] = false, plus the current value
> of column k.
> The way this was handled so far is that the PREPARED response contains no
> result set metadata, and therefore all EXECUTE messages have SKIP_METADATA =
> false, and the responses always include the full (and correct) metadata.
> CASSANDRA-10786 still sends the PREPARED response with no metadata, *but the
> response to EXECUTE now contains a {{new_metadata_id}}*. The driver thinks it
> is because of a schema change, and updates its local copy of the prepared
> statement's result metadata.
> The next EXECUTE is sent with SKIP_METADATA = true, but the server appears to
> ignore that, and still sends the metadata in the response. So each response
> includes the correct metadata, the driver uses it, and there is no visible
> issue for client code.
> The only drawback is that the driver updates its local copy of the metadata
> unnecessarily, every time. We can work around that by only updating if we had
> metadata before, at the cost of an extra volatile read. But I think the best
> thing to do would be to never send a {{new_metadata_id}} in for a conditional
> update.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
