[
https://issues.apache.org/jira/browse/CASSANDRA-13992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16254639#comment-16254639
]
Kurt Greaves commented on CASSANDRA-13992:
------------------------------------------
bq. But then I would have to compare the ids every time. That costs me a lookup
in my client-side prepared statement cache (and there also happens to be an
additional volatile read in our current implementation). In contrast, checking
METADATA_CHANGED is free since it is already in the response.
OK I get it.
bq. I thought we have discussed it and I've tried this idea out and it doesn't
solve the problem with actually updating the metadata when performing ALTER.
Just trying to understand things here but from what I can see the patches both
provide the same behaviour. Notably, METADATA_CHANGED will never be set for LWT
but the metadata will still always be returned to the client. Anyway, you can
do it that way if you want seeing as it helps on the java driver side.
But now that I think about it more and after some testing I don't see how
either case works completely for {{ALTER}}. When you say ALTER what are you
referring to? AFAICT all you can do is add + drop columns that aren't used in
the prepared statement, and atm both patches behave in the exact same way. If
you alter any column used in the statement it invalidates the statement and you
get an error. What aspects of ALTER are you expecting to work?
> 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
