[ https://issues.apache.org/jira/browse/CASSANDRA-13992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16252848#comment-16252848 ]
Kurt Greaves commented on CASSANDRA-13992: ------------------------------------------ I don't see why special casing LWT is necessary. It couples LWT, {{ModificationStatement}} and {{BatchStatement}} with {{ExecuteMessage}}, which seems a bit messy. It also introduces a weird edge case into the protocol - i.e, 1. you can't skip metadata for LWT 2. metadata will never be changed for LWT. 2 is fine as it's somewhat the goal of the ticket, but when we already have a mechanism to meet this requirement it seems silly to wrap it in another. 1 just adds complexity to the protocol, which imo, is complex enough. It's not even clear in the protocol that SKIP_METADATA will be ignored if the metadata *did* change (we should update this in the patch). I think this can be better solved simply by providing a consistent MD5 for LWT's as my patch already does [here|https://github.com/apache/cassandra/compare/trunk...kgreav:13992]. This removes the need to introduce new imports, and special casing to {{ExecuteMessage}} while achieving the same behaviour, and I think logically is easier to explain. AFAICT [~ifesdjeen]'s patch only really works because the driver is already set up for it to work. The _java_ driver already checks that {{new_metadata_id != null}} which is logical, but in no way required. It seems to me we're introducing a metadata_id that could potentially be null where a driver might expect it to have a value. I prefer my patch, or better yet, we create an {{EMPTY_DIGEST}} that's an actual MD5 to use so we don't have to rely on {{compute}} every time we want to use an {{EMPTY_DIGEST}} > 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