[
https://issues.apache.org/jira/browse/CASSANDRA-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606047#comment-17606047
]
Alex Petrov commented on CASSANDRA-17248:
-----------------------------------------
It looks like this indeed is what is happening here. Unqualified queries should
have included the provided keyspace at all times. In the caches path we even
have a comment saying {{For non-fully qualified statements, we always include
keyspace to avoid ambiguity}}, and other comments say the same {{Query prepared
on a 3.0.25 instance needs to return hash 1(fully qualified query with
keyspace)/3(unqualified query with keyspace) to be able to execute it on a
3.0.25 instance}} and we seem to return a correct hash from cashes. I think
that it is enough to just return {{nonQualifiedWithKeyspace}}, and it'll cover
all versions, but I'd still run a mixed-mode fuzz test from 4.0.
cc [~marcuse]
> Fix Prepared Statements behaviours after 15252
> ----------------------------------------------
>
> Key: CASSANDRA-17248
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17248
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
> Reporter: Alex Petrov
> Assignee: Alex Petrov
> Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2
>
>
> [CASSANDRA-15252] has fixed an important issue: unwanted hash changes when
> preparing fully qualified prepared statements which was causing
> cluster-killing re-prepare loops. However, the fix introduced a regression:
> non-qualified statements can get prepared against one keyspace but then
> executed on another under some circumstances. This patch reconciles all
> behaviours.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
