[
https://issues.apache.org/jira/browse/CASSANDRA-20028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
João Reis updated CASSANDRA-20028:
----------------------------------
Description:
CASSANDRA-10786 added the METADATA_CHANGED flag to the v5 spec (ROWS RESPONSE).
Drivers are supposed to handle this flag and update their locally cached
prepared statement object with the new metadata.
As we're working to implement v5 support on GoCQL we are trying to trigger a
scenario where C* returns this flag but we are unable to. Instead we receive an
UNPREPARED which causes the driver to re-prepare the statement. This flag was
added to avoid this scenario so I don't really understand if there is a bug
somewhere or if the test case we're creating is not valid?
I ran the following steps against C* 4.0-rc1, 4.0.0 and 5.0.2 with the same
results:
{code}
CREATE KEYSPACE testks WITH REPLICATION = { 'class': 'SimpleStrategy',
'replication_factor': 1 }
CREATE TABLE testks.testtable (id uuid PRIMARY KEY, txt TEXT)
INSERT INTO testks.testtable(id, txt) VALUES (uuid(), 'test')
// PREPARED_ID: 2bea4b54ec20bd3533f7b91467abb618
// RESULT METADATA ID: 1f685bd34ed0ba1e99ba6bd960da2545
SELECT * FROM testks.testtable
ALTER TABLE testks.testtable ADD (txt2 TEXT)
INSERT INTO testks.testtable(id, txt, txt2) VALUES (uuid(), 'test2', 'test222')
// this SELECT gets an UNPREPARED response from the server
// instead of a ROWS response with the new metadata
//
// after RE-PREPARE:
// PREPARED_ID: 2bea4b54ec20bd3533f7b91467abb618
// RESULT METADATA ID: 87257e07eccd14a6c8e623012af9278a
SELECT * FROM testtable
{code}
Note that v5 support on gocql is still WIP so I imported gocql [from this
branch|https://github.com/apache/cassandra-gocql-driver/pull/1822] to test this
with gocql.
I believe [~lukasz.antoniak] was able to reproduce this with the java driver
which has had v5 support for a while and got the same results, I'll ask him to
post a comment on this ticket.
*UPDATE*
If the last SELECT is sent with the old metadata ID then we are able to see the
METADATA_CHANGED flag but this would only occur if the driver does not update
its local prepared statement object after the re-PREPARE. The expected behavior
is that no re-PREPARE is needed in the first place.
was:
CASSANDRA-10786 added the METADATA_CHANGED flag to the v5 spec (ROWS RESPONSE).
Drivers are supposed to handle this flag and update their locally cached
prepared statement object with the new metadata.
As we're working to implement v5 support on GoCQL we are trying to trigger a
scenario where C* returns this flag but we are unable to. Instead we receive an
UNPREPARED which causes the driver to re-prepare the statement. This flag was
added to avoid this scenario so I don't really understand if there is a bug
somewhere or if the test case we're creating is not valid?
I ran the following steps against C* 4.0-rc1, 4.0.0 and 5.0.2 with the same
results:
{code}
CREATE KEYSPACE testks WITH REPLICATION = { 'class': 'SimpleStrategy',
'replication_factor': 1 }
CREATE TABLE testks.testtable (id uuid PRIMARY KEY, txt TEXT)
INSERT INTO testks.testtable(id, txt) VALUES (uuid(), 'test')
// PREPARED_ID: 2bea4b54ec20bd3533f7b91467abb618
// RESULT METADATA ID: 1f685bd34ed0ba1e99ba6bd960da2545
SELECT * FROM testks.testtable
ALTER TABLE testks.testtable ADD (txt2 TEXT)
INSERT INTO testks.testtable(id, txt, txt2) VALUES (uuid(), 'test2', 'test222')
// this SELECT gets an UNPREPARED response from the server
// instead of a ROWS response with the new metadata
//
// after RE-PREPARE:
// PREPARED_ID: 2bea4b54ec20bd3533f7b91467abb618
// RESULT METADATA ID: 87257e07eccd14a6c8e623012af9278a
SELECT * FROM testtable
{code}
Note that v5 support on gocql is still WIP so I imported gocql [from this
branch|https://github.com/apache/cassandra-gocql-driver/pull/1822] to test this
with gocql.
I believe [~lukasz.antoniak] was able to reproduce this with the java driver
which has had v5 support for a while and got the same results, I'll ask him to
post a comment on this ticket.
> METADATA_CHANGED is never set
> -----------------------------
>
> Key: CASSANDRA-20028
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20028
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
> Reporter: João Reis
> Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> CASSANDRA-10786 added the METADATA_CHANGED flag to the v5 spec (ROWS
> RESPONSE). Drivers are supposed to handle this flag and update their locally
> cached prepared statement object with the new metadata.
> As we're working to implement v5 support on GoCQL we are trying to trigger a
> scenario where C* returns this flag but we are unable to. Instead we receive
> an UNPREPARED which causes the driver to re-prepare the statement. This flag
> was added to avoid this scenario so I don't really understand if there is a
> bug somewhere or if the test case we're creating is not valid?
> I ran the following steps against C* 4.0-rc1, 4.0.0 and 5.0.2 with the same
> results:
> {code}
> CREATE KEYSPACE testks WITH REPLICATION = { 'class': 'SimpleStrategy',
> 'replication_factor': 1 }
> CREATE TABLE testks.testtable (id uuid PRIMARY KEY, txt TEXT)
> INSERT INTO testks.testtable(id, txt) VALUES (uuid(), 'test')
> // PREPARED_ID: 2bea4b54ec20bd3533f7b91467abb618
> // RESULT METADATA ID: 1f685bd34ed0ba1e99ba6bd960da2545
> SELECT * FROM testks.testtable
> ALTER TABLE testks.testtable ADD (txt2 TEXT)
> INSERT INTO testks.testtable(id, txt, txt2) VALUES (uuid(), 'test2',
> 'test222')
> // this SELECT gets an UNPREPARED response from the server
> // instead of a ROWS response with the new metadata
> //
> // after RE-PREPARE:
> // PREPARED_ID: 2bea4b54ec20bd3533f7b91467abb618
> // RESULT METADATA ID: 87257e07eccd14a6c8e623012af9278a
> SELECT * FROM testtable
> {code}
> Note that v5 support on gocql is still WIP so I imported gocql [from this
> branch|https://github.com/apache/cassandra-gocql-driver/pull/1822] to test
> this with gocql.
> I believe [~lukasz.antoniak] was able to reproduce this with the java driver
> which has had v5 support for a while and got the same results, I'll ask him
> to post a comment on this ticket.
> *UPDATE*
> If the last SELECT is sent with the old metadata ID then we are able to see
> the METADATA_CHANGED flag but this would only occur if the driver does not
> update its local prepared statement object after the re-PREPARE. The expected
> behavior is that no re-PREPARE is needed in the first place.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
