Indices on Cassandra 2.x may not have indexType, which breaks schema refresh and driver startup
Description
In certain cases, when building IndexMetadata for schema from (legacy) Cassandra <=2.2, an indexed column may be missing its indexType. This results in TableParser#buildLegacyIndex throwing an NPE (via IndexKind.valueOf(null)) during the initial schema refresh, rendering the user unable to create a session unless they disable schema for the offending keyspaces (or globally, although for anyone using spring-data-cassandra that’s blocked by ).
I’m not sure in which cases the indices are missing a type, since I see indices for one table with the index_type while indices for another table have all the types. This is old and likely deprecated data that we haven’t touched in a while.
Example stack trace:
Environment
Tested with existing indices in Cassandra 2.1.
Pull Requests
None
Attachments
1
Activity
Show:
Ammar Khaku
April 14, 2022 at 4:25 AM
Happy to create a PR for this. I don’t fully understand the implications here though - naively I’d skip past the bad index by returning null but perhaps we should instead be treating a missing type as IndexKeys.KEYS?
In certain cases, when building IndexMetadata for schema from (legacy) Cassandra <=2.2, an indexed column may be missing its indexType. This results in TableParser#buildLegacyIndex throwing an NPE (via IndexKind.valueOf(null)) during the initial schema refresh, rendering the user unable to create a session unless they disable schema for the offending keyspaces (or globally, although for anyone using spring-data-cassandra that’s blocked by ).
I’m not sure in which cases the indices are missing a type, since I see indices for one table with the index_type while indices for another table have all the types. This is old and likely deprecated data that we haven’t touched in a while.
Example stack trace: