[
https://issues.apache.org/jira/browse/CASSANDRA-13992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249838#comment-16249838
]
Olivier Michallat edited comment on CASSANDRA-13992 at 11/13/17 5:18 PM:
-------------------------------------------------------------------------
[~ifesdjeen] that would work, the driver can treat an empty {{new_metadata_id}}
as "don't update my local copy". Namely, changing [this
line|https://github.com/datastax/java-driver/blob/6eeb8b2193ab5b50b73b0d9a533e775265f11007/driver-core/src/main/java/com/datastax/driver/core/ArrayBackedResultSet.java#L83]
to:
{code}
if (newMetadataId != null && newMetadataId.bytes.length > 0) {
{code}
However that feels kind of hacky. Consider how we would have to explain that in
the protocol spec:
{quote}
- <new_metadata_id> is \[short bytes] representing the new, changed
resultset
metadata. The new metadata ID must also be used in subsequent
executions of
the corresponding prepared statement, if any, *except if it is
empty*.
{quote}
It would make so much more sense to force {{METADATA_CHANGED}} to *false* for
conditional updates, isn't there any way we can do that?
was (Author: omichallat):
[~ifesdjeen] that would work, the driver can treat an empty {{new_metadata_id}}
as "don't update my local copy". Namely, changing [this
line|https://github.com/datastax/java-driver/blob/6eeb8b2193ab5b50b73b0d9a533e775265f11007/driver-core/src/main/java/com/datastax/driver/core/ArrayBackedResultSet.java#L83]
to:
{code}
if (newMetadataId != null && newMetadataId.bytes.length > 0) {
{code}
However that feels kind of hacky. Consider how we would have to update the
protocol spec to explain this:
{quote}
- <new_metadata_id> is \[short bytes] representing the new, changed
resultset
metadata. The new metadata ID must also be used in subsequent
executions of
the corresponding prepared statement, if any, *except if it is
empty*.
{quote}
It would make so much more sense to force {{METADATA_CHANGED}} to *false* for
conditional statements, isn't there any way we can do that?
> 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: [email protected]
For additional commands, e-mail: [email protected]
