Olivier Michallat created CASSANDRA-13992:
---------------------------------------------

             Summary: 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
            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

Reply via email to