[ 
https://issues.apache.org/jira/browse/CASSANDRA-20350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cameron Zemek updated CASSANDRA-20350:
--------------------------------------
    Description: 
{color:red}colored text{color}The change in CASSANDRA-15252 has broken behavior 
with unqualified prepare statements during upgrade. Prior to the change the 
behavior was:

 
{code:java}
    public static ResultMessage.Prepared prepare(String queryString, 
ClientState clientState, boolean forThrift)
    {
        // omitted for brevity
        return storePreparedStatement(queryString, 
clientState.getRawKeyspace(), prepared, forThrift);
    } {code}
 

After the change it has:

 
{code:java}
            ResultMessage.Prepared nonQualifiedWithKeyspace = 
storePreparedStatement(queryString, clientState.getRawKeyspace(), prepared, 
forThrift);
            ResultMessage.Prepared nonQualifiedWithNullKeyspace = 
storePreparedStatement(queryString, null, prepared, forThrift);
            if (!useNewPreparedStatementBehaviour)
                return nonQualifiedWithNullKeyspace;

            return nonQualifiedWithKeyspace; {code}
 

Where {{useNewPreparedStatementBehaviour}} is set to false while any node in 
the cluster is less than 3.11.12 . Note that it returns 
{{nonQualifiedWithNullKeyspace}} , whereas in 3.11.11 it returns the one with 
the keyspace.

 

And as further evidence at the top of the prepare method when using the cache 
during upgrade it has:
{code:java}
                else // legacy caches, pre-CASSANDRA-15252 behaviour
                {
                    return new ResultMessage.Prepared(hashWithKeyspace, 
cachedWithKeyspace);
                } {code}
The solution to revert it to legacy behavior during upgrade is the following 
patch:
{code:java}
diff --git a/src/java/org/apache/cassandra/cql3/QueryProcessor.java 
b/src/java/org/apache/cassandra/cql3/QueryProcessor.java
index 7de33a78b9..b2bb7f4f61 100644
--- a/src/java/org/apache/cassandra/cql3/QueryProcessor.java
+++ b/src/java/org/apache/cassandra/cql3/QueryProcessor.java
@@ -533,8 +533,6 @@ public class QueryProcessor implements QueryHandler

             ResultMessage.Prepared nonQualifiedWithKeyspace = 
storePreparedStatement(queryString, clientState.getRawKeyspace(), prepared, 
forThrift);
             ResultMessage.Prepared nonQualifiedWithNullKeyspace = 
storePreparedStatement(queryString, null, prepared, forThrift);
-            if (!useNewPreparedStatementBehaviour)
-                return nonQualifiedWithNullKeyspace;

             return nonQualifiedWithKeyspace;
         } {code}

  was:
The change in CASSANDRA-15252 has broken behavior with unqualified prepare 
statements during upgrade. Prior to the change the behavior was:

 
{code:java}
    public static ResultMessage.Prepared prepare(String queryString, 
ClientState clientState, boolean forThrift)
    {
        // omitted for brevity
        return storePreparedStatement(queryString, 
clientState.getRawKeyspace(), prepared, forThrift);
    } {code}
 

After the change it has:

 
{code:java}
            ResultMessage.Prepared nonQualifiedWithKeyspace = 
storePreparedStatement(queryString, clientState.getRawKeyspace(), prepared, 
forThrift);
            ResultMessage.Prepared nonQualifiedWithNullKeyspace = 
storePreparedStatement(queryString, null, prepared, forThrift);
            if (!useNewPreparedStatementBehaviour)
                return nonQualifiedWithNullKeyspace;

            return nonQualifiedWithKeyspace; {code}
 

Where {{useNewPreparedStatementBehaviour}} is set to false while any node in 
the cluster is less than 3.11.12 . Note that it returns 
{{nonQualifiedWithNullKeyspace}} , whereas in 3.11.11 it returns the one with 
the keyspace.

 

And as further evidence at the top of the prepare method when using the cache 
during upgrade it has:
{code:java}
                else // legacy caches, pre-CASSANDRA-15252 behaviour
                {
                    return new ResultMessage.Prepared(hashWithKeyspace, 
cachedWithKeyspace);
                } {code}
The solution to revert it to legacy behavior during upgrade is the following 
patch:
{code:java}
diff --git a/src/java/org/apache/cassandra/cql3/QueryProcessor.java 
b/src/java/org/apache/cassandra/cql3/QueryProcessor.java
index 7de33a78b9..b2bb7f4f61 100644
--- a/src/java/org/apache/cassandra/cql3/QueryProcessor.java
+++ b/src/java/org/apache/cassandra/cql3/QueryProcessor.java
@@ -533,8 +533,6 @@ public class QueryProcessor implements QueryHandler

             ResultMessage.Prepared nonQualifiedWithKeyspace = 
storePreparedStatement(queryString, clientState.getRawKeyspace(), prepared, 
forThrift);
             ResultMessage.Prepared nonQualifiedWithNullKeyspace = 
storePreparedStatement(queryString, null, prepared, forThrift);
-            if (!useNewPreparedStatementBehaviour)
-                return nonQualifiedWithNullKeyspace;

             return nonQualifiedWithKeyspace;
         } {code}


> Unqualified prepared statements break during upgrade due to CASSANDRA-15252
> ---------------------------------------------------------------------------
>
>                 Key: CASSANDRA-20350
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-20350
>             Project: Apache Cassandra
>          Issue Type: Bug
>            Reporter: Cameron Zemek
>            Assignee: Stefan Miklosovic
>            Priority: Normal
>             Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> {color:red}colored text{color}The change in CASSANDRA-15252 has broken 
> behavior with unqualified prepare statements during upgrade. Prior to the 
> change the behavior was:
>  
> {code:java}
>     public static ResultMessage.Prepared prepare(String queryString, 
> ClientState clientState, boolean forThrift)
>     {
>         // omitted for brevity
>         return storePreparedStatement(queryString, 
> clientState.getRawKeyspace(), prepared, forThrift);
>     } {code}
>  
> After the change it has:
>  
> {code:java}
>             ResultMessage.Prepared nonQualifiedWithKeyspace = 
> storePreparedStatement(queryString, clientState.getRawKeyspace(), prepared, 
> forThrift);
>             ResultMessage.Prepared nonQualifiedWithNullKeyspace = 
> storePreparedStatement(queryString, null, prepared, forThrift);
>             if (!useNewPreparedStatementBehaviour)
>                 return nonQualifiedWithNullKeyspace;
>             return nonQualifiedWithKeyspace; {code}
>  
> Where {{useNewPreparedStatementBehaviour}} is set to false while any node in 
> the cluster is less than 3.11.12 . Note that it returns 
> {{nonQualifiedWithNullKeyspace}} , whereas in 3.11.11 it returns the one with 
> the keyspace.
>  
> And as further evidence at the top of the prepare method when using the cache 
> during upgrade it has:
> {code:java}
>                 else // legacy caches, pre-CASSANDRA-15252 behaviour
>                 {
>                     return new ResultMessage.Prepared(hashWithKeyspace, 
> cachedWithKeyspace);
>                 } {code}
> The solution to revert it to legacy behavior during upgrade is the following 
> patch:
> {code:java}
> diff --git a/src/java/org/apache/cassandra/cql3/QueryProcessor.java 
> b/src/java/org/apache/cassandra/cql3/QueryProcessor.java
> index 7de33a78b9..b2bb7f4f61 100644
> --- a/src/java/org/apache/cassandra/cql3/QueryProcessor.java
> +++ b/src/java/org/apache/cassandra/cql3/QueryProcessor.java
> @@ -533,8 +533,6 @@ public class QueryProcessor implements QueryHandler
>              ResultMessage.Prepared nonQualifiedWithKeyspace = 
> storePreparedStatement(queryString, clientState.getRawKeyspace(), prepared, 
> forThrift);
>              ResultMessage.Prepared nonQualifiedWithNullKeyspace = 
> storePreparedStatement(queryString, null, prepared, forThrift);
> -            if (!useNewPreparedStatementBehaviour)
> -                return nonQualifiedWithNullKeyspace;
>              return nonQualifiedWithKeyspace;
>          } {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to