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

Stefania updated CASSANDRA-12815:
---------------------------------
    Description: 
Since CASSANDRA-11534 there is a potential bug in this code:

{code}
    if result.column_types:
            ks_meta = self.conn.metadata.keyspaces[table_meta.keyspace_name]
            cql_types = [CqlType(cql_typename(t), ks_meta) for t in 
result.column_types]
{code}

It cannot be reproduced with any of our tests but there is a code path that 
could cause {{table_meta}} to be {{None}} when the statement cannot be parsed. 
Given that the code before 11534 used to check on {{table_meta}} not being 
{{None}}, I prefer to put back the same check in order to avoid any possible 
regressions once 3.10 is released. Also, since we check in all other places, 
this helps with consistency too.

The only reason we need the table metadata in that code block is to get the 
keyspace name. We should fallback to the current keyspace name if we have no 
table metadata.

  was:
Since CASSANDRA-11534 there is a potential bug in this code:

{code}
if result.column_types:
            ks_meta = self.conn.metadata.keyspaces[table_meta.keyspace_name]
            cql_types = [CqlType(cql_typename(t), ks_meta) for t in 
result.column_types]
{code}

It cannot be reproduced with any of our tests but there is a code path that 
could cause {{table_meta}} to be {{None}} when the statement cannot be parsed. 
Given that the code before 11534 used to check on {{table_meta}} not being 
{{None}}, I prefer to put back the same check in order to avoid any possible 
regressions once 3.10 is released. Also, since we check in all other places, 
this helps with consistency too.

The only reason we need the table metadata in that code block is to get the 
keyspace name. We should fallback to the current keyspace name if we have no 
table metadata.


> cqlsh may throw AttributeError due to no table metadata
> -------------------------------------------------------
>
>                 Key: CASSANDRA-12815
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12815
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Tools
>            Reporter: Stefania
>            Assignee: Stefania
>             Fix For: 3.10
>
>
> Since CASSANDRA-11534 there is a potential bug in this code:
> {code}
>     if result.column_types:
>             ks_meta = self.conn.metadata.keyspaces[table_meta.keyspace_name]
>             cql_types = [CqlType(cql_typename(t), ks_meta) for t in 
> result.column_types]
> {code}
> It cannot be reproduced with any of our tests but there is a code path that 
> could cause {{table_meta}} to be {{None}} when the statement cannot be 
> parsed. Given that the code before 11534 used to check on {{table_meta}} not 
> being {{None}}, I prefer to put back the same check in order to avoid any 
> possible regressions once 3.10 is released. Also, since we check in all other 
> places, this helps with consistency too.
> The only reason we need the table metadata in that code block is to get the 
> keyspace name. We should fallback to the current keyspace name if we have no 
> table metadata.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to