Migration from Cassandra 2.x to 3.x: schema_keyspaces table is gone. How do you query system keyspaces?

Question

I just migrated from Cassandra 2.x to 3.x (specifically, 3.4). Now the system tables have completely changed, and these changes are not in the documentation. If you look at the current CQL docs for system tables, they only describe the system schema as it was in 2.X.

CQL 3.3 Docs for Cassandra 2.X and greater

Does anyone out there have access docs that detail this change? How do I query to see what keyspaces are available?

There is a new system keyspace called "system_schema", but there are only two tables in it: system_schema.tables and system_schema.columns. So I'm at a loss as to where to look for the information I need (I need to be able to effectively do a DESCRIBE KEYSPACES command, but outside of cqlsh).

Is the answer this: SELECT keyspace_name FROM system_schema.tables; the new way to do this?

Answer 1

So I found there is a better way: you go through the API. I got the idea from this answer:

https://stackoverflow.com/a/35182348/2933397

You need to access the keyspace metadata directly. So an example of how to access the schema metadata is here:

Cassandra CPP driver: UDF Metadata

The idea is to obtain a pointer to a CassSchemaMeta object, then you have access to all of the keyspaces, tables, columns, functions, etc.

http://datastax.github.io/cpp-driver/api/struct.CassSchemaMeta/

As a side note, I needed this information so I could support schema perusal in C++. We created a wrapper library which provides C++ bindings, and the Schema stuff is supported here:

https://github.com/m2osw/libcasswrapper

Answer 2

There is a new system keyspace called "system_schema", but there are only two tables in it:

Ok something must have gone wrong in your upgrade, because that's not right. When I check my system_schema 3.4, I see this:

[cqlsh 5.0.1 | Cassandra 3.4 | CQL spec 3.4.0 | Native protocol v4]
Use HELP for help.
aploetz@cqlsh> use system_schema ;
aploetz@cqlsh:system_schema> desc tables;

tables     triggers    views    keyspaces  dropped_columns
functions  aggregates  indexes  types      columns  

There are definitely more than two tables in that keyspace.

How do I query to see what keyspaces are available?

The new way to do this, is to query system_schema.keyspaces:

aploetz@cqlsh:system_schema> SELECT * FROM keyspaces;

 keyspace_name          | durable_writes | replication
------------------------+----------------+-------------------------------------------------------------------------------------
        zeroreplication |           True |       {'DC1': '0', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
            system_auth |           True | {'class': 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
          system_schema |           True |                             {'class': 'org.apache.cassandra.locator.LocalStrategy'}
          experfy_class |           True |       {'DC1': '1', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
                 system |           True |                             {'class': 'org.apache.cassandra.locator.LocalStrategy'}
          stackoverflow |           True |       {'DC1': '1', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}
              eqcontrol |           True |       {'DC1': '1', 'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy'}

The main difference between system.schema_keyspaces and system_schema.keyspaces, is that system_schema.keyspaces only has 3 columns instead of two (strategy_class and strategy_options were combined into replication).