You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stefan Miklosovic (Jira)" <ji...@apache.org> on 2024/08/05 20:00:00 UTC
[jira] [Comment Edited] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[ https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871151#comment-17871151 ]
Stefan Miklosovic edited comment on CASSANDRA-18322 at 8/5/24 7:59 PM:
-----------------------------------------------------------------------
[~ifesdjeen] [~blerer]
Imagine we process a batch statement [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L455-L457]. When we do not use fully qualified table, then isFullyQualified returns false [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L627-L634]. Then, we go to do
{code}
qualifiedStatement.setKeyspace(clientState);
keyspace = qualifiedStatement.keyspace();
{code}
so we set a keyspace from clientState (when there is no keyspace for a statement in a batch and a user used USE), but then, qualifiedStatement.keyspace() returns null.
{code}
@Override
public String keyspace()
{
return null;
}
{code}
The result of this logic is that we just lost the information about a keyspace in a batch. So on one hand, we are setting a keyspace of each statement yet when we ask what keyspace it is executed on it is null?
How I detected this is that when I run cassandra-dtest with the patch, it started to fail some tests when I have not specified fully qualified statements in a batch while it was using USE and it logged an error while the test was not prepared for such error logging statement. I think we should do something like this:
{code}
@Override
public String keyspace()
{
if (parsedStatements.isEmpty())
return null;
String currentKeyspace = null;
for (ModificationStatement.Parsed statement : parsedStatements)
{
String keyspace = statement.keyspace();
if (keyspace == null && currentKeyspace != null)
return null;
if (keyspace != null && currentKeyspace == null)
{
currentKeyspace = keyspace;
continue;
}
if (currentKeyspace != null && !currentKeyspace.equals(keyspace))
return null;
}
return currentKeyspace;
}
{code}
was (Author: smiklosovic):
[~ifesdjeen] [~blerer]
Imagine we process a batch statement [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L455-L457] When we do not use fully qualified table, then isFullyQualified returns false [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/BatchStatement.java#L627-L634]. Then, we go to do
{code}
qualifiedStatement.setKeyspace(clientState);
keyspace = qualifiedStatement.keyspace();
{code}
so we set a keyspace from clientState (when there is no keyspace for a statement in a batch and a user used USE), but then, qualifiedStatement.keyspace() returns null.
{code}
@Override
public String keyspace()
{
return null;
}
{code}
The result of this logic is that we just lost the information about a keyspace in a batch. So on one hand, we are setting a keyspace of each statement yet when we ask what keyspace it is executed on it is null?
How I detected this is that when I run cassandra-dtest with the patch, it started to fail some tests when I have not specified fully qualified statements in a batch while it was using USE and it logged an error while the test was not prepared for such error logging statement. I think we should do something like this:
{code}
@Override
public String keyspace()
{
if (parsedStatements.isEmpty())
return null;
String currentKeyspace = null;
for (ModificationStatement.Parsed statement : parsedStatements)
{
String keyspace = statement.keyspace();
if (keyspace == null && currentKeyspace != null)
return null;
if (keyspace != null && currentKeyspace == null)
{
currentKeyspace = keyspace;
continue;
}
if (currentKeyspace != null && !currentKeyspace.equals(keyspace))
return null;
}
return currentKeyspace;
}
{code}
> Warn about unqualified prepared statement only if it is a select, update, delete, insert
> ----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
> Reporter: Mohammad Aburadeh
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create keyspace ... " or "drop keyspace" statements.
> "
> {{USE <keyspace>}} with prepared statements is considered to be an anti-pattern due to ambiguity in non-qualified table names. Please consider removing instances of {{{}Session#setKeyspace(<keyspace>){}}}, {{Session#execute("USE <keyspace>")}} and {{cluster.newSession(<keyspace>)}} from your code, and always use fully qualified table names (e.g. <keyspace>.<table>). Keyspace used: null, statement keyspace: null, statement id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org