apache/cassandra · error · InvalidRequestException
Cannot use CREATE TABLE LIKE on an index table '%s.%s'.
Error message
Cannot use CREATE TABLE LIKE on an index table '%s.%s'.
What it means
CREATE TABLE LIKE cannot be used with an index (specifically a legacy secondary-index-backed table) as its source. CopyTableStatement.apply() checks sourceTableMeta.isIndex() after resolving the source and throws this InvalidRequestException, because an index is derived metadata, not a standalone table that can be cloned.
Source
Thrown at src/java/org/apache/cassandra/cql3/statements/schema/CopyTableStatement.java:136
return metadata.directory.commonSerializationVersion.isAtLeast(Version.V5);
}
@Override
public Keyspaces apply(ClusterMetadata metadata)
{
Keyspaces schema = metadata.schema.getKeyspaces();
KeyspaceMetadata sourceKeyspaceMeta = schema.getNullable(sourceKeyspace);
if (null == sourceKeyspaceMeta)
throw ire("Source Keyspace '%s' doesn't exist", sourceKeyspace);
TableMetadata sourceTableMeta = sourceKeyspaceMeta.getTableOrViewNullable(sourceTableName);
if (null == sourceTableMeta)
throw ire("Source Table '%s.%s' doesn't exist", sourceKeyspace, sourceTableName);
if (sourceTableMeta.isIndex())
throw ire("Cannot use CREATE TABLE LIKE on an index table '%s.%s'.", sourceKeyspace, sourceTableName);
if (sourceTableMeta.isView())
throw ire("Cannot use CREATE TABLE LIKE on a materialized view '%s.%s'.", sourceKeyspace, sourceTableName);
KeyspaceMetadata targetKeyspaceMeta = schema.getNullable(targetKeyspace);
if (null == targetKeyspaceMeta)
throw ire("Target Keyspace '%s' doesn't exist", targetKeyspace);
if (targetKeyspaceMeta.hasTable(targetTableName))
{
if (ifNotExists)
return schema;
throw new AlreadyExistsException(targetKeyspace, targetTableName);
}
if (!sourceKeyspace.equalsIgnoreCase(targetKeyspace))
{View on GitHub (pinned to 88fd0f6a0e)
Solutions
- Point LIKE at the base table the index belongs to, then recreate the index on the new table with CREATE INDEX/CREATE CUSTOM INDEX
- Filter out index tables when generating CREATE TABLE LIKE statements programmatically
- Drop/rename the confusingly named index if it shadows a table name (rare)
Example fix
// before CREATE TABLE ks2.idx_copy LIKE ks.tab_by_email_idx; // after CREATE TABLE ks2.tab_copy LIKE ks.tab; CREATE INDEX ON ks2.tab_copy (email);
Defensive patterns
Strategy: validation
Validate before calling
// Skip index-backed tables by joining system_schema.indexes
const rows = await session.execute(
`SELECT t.table_name FROM system_schema.tables t
LEFT JOIN system_schema.indexes i
ON t.keyspace_name=i.keyspace_name AND t.table_name=i.table_name
WHERE t.keyspace_name=? AND t.table_name=? AND i.index_name IS NULL`,
[srcKs, srcTable]);
if (rows.rows.length === 0) throw new Error(`${srcKs}.${srcTable} is an index table; use its base table`); Type guard
null
Try / catch
try {
session.execute(`CREATE TABLE t2 LIKE ${name}`);
} catch (e) {
if (/CREATE TABLE LIKE on an index table/.test(e.message)) {
// resolve base table and recreate the index afterward
} else throw e;
} Prevention
- When cloning whole keyspaces, filter out index tables from system_schema.tables
- Recreate indexes with CREATE INDEX on the copied table instead of copying them
- Exclude system/internal tables from bulk copy scripts
When it happens
Trigger: `CREATE TABLE t2 LIKE <ks>.<name>` where <name> resolves to an index table (e.g. the internal table backing a 2i / SAI index).
Common situations: Scripting schema clones by iterating all names in a keyspace (system_schema.tables includes index-backed entries); attempting to copy an index's structure instead of creating an index on the copied table.
Understand the failure class
Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.
Related errors
- Cannot use CREATE TABLE LIKE on a materialized view '%s.%s'.
- %s
- Altering field types is no longer supported
- Source Keyspace '%s' doesn't exist
- Source Table '%s.%s' doesn't exist
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/5c548e94c69f5c31.
Report an issue: GitHub.