cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Olivier Michallat (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13992) Don't send new_metadata_id for conditional updates
Date Mon, 13 Nov 2017 03:27:00 GMT


Olivier Michallat commented on CASSANDRA-13992:

bq. Before I waste a lot of time figuring out how to test this in the driver, can you point
me at how you did it?

The driver-side changes are not merged yet, but you can find them in [this pull request|].
The test that covers this specific scenario is [PreparedStatementInvalidationTest#should_never_update_statement_id_for_conditional_updates_in_modern_protocol|].

To run the test you'll need to install CCM (see some instructions [here|]).
Then because you're not testing a released Cassandra version, you'll need to point the test
harness to your local working copy with those system properties: {{-Dcassandra.version=4.0.0}}

If you want to do some debugging, the result metadata is handled in {{}}.
Search for "CASSANDRA-13992", there is a comment that explains what should be changed if this
ticket is fixed.

> Don't send new_metadata_id for conditional updates
> --------------------------------------------------
>                 Key: CASSANDRA-13992
>                 URL:
>             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}
> {code}
> And the prepared statement
> {code}
> {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
> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message