[
https://issues.apache.org/jira/browse/CASSANDRA-13992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16253022#comment-16253022
]
Olivier Michallat commented on CASSANDRA-13992:
-----------------------------------------------
[~ifesdjeen] yes, your last patch is fine for me from a client's perspective (I
can't really comment on the implementation since I'm not that familiar with the
Cassandra codebase).
[~KurtG]:
bq. you can't skip metadata for LWT
Nor should you be able to. You can't safely skip metadata since these
statements may return different columns depending on the state of the database.
You _have_ to return the metadata every time.
bq. metadata will never be changed for LWT
We don't need it since every response includes the correct metadata.
bq. AFAICT Alex Petrov's patch only really works because the driver is already
set up for it to work.
Actually no, it allows the driver to treat LWT as any other statement. Here's
roughly what we do:
{code}
// When decoding a PREPARED response
if ! NO_METADATA // Note that LWT always have NO_METADATA
store result metadata in prepared statement cache
end if
// When decoding a ROWS response:
if NO_METADATA
look up result metadata in prepared statement cache
else
decode result metadata from response
if (METADATA_CHANGED)
update result metadata in prepared statement cache
end if
end if
{code}
So unsetting {{METADATA_CHANGED}} for LWT allows me to properly skip the last
cache update. If we use a special value of {{new_metadata_id}} instead (like
the empty array in the initial patch), then I have to change the last test to
{{if (METADATA_CHANGED || new_metadata_id == special_value)}}.
HTH
> 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
