apache/cassandra · error · InvalidRequestException

Altering field types is no longer supported

Error message

Altering field types is no longer supported

What it means

Altering the type of an existing field inside a user-defined type (UDT) is no longer allowed in this version of Cassandra. The AlterTypeStatement's FieldTypeAlteration.apply() unconditionally raises this InvalidRequestException because field-type changes broke serialization compatibility and were removed. Developers must create a new UDT instead of mutating field types in place.

Source

Thrown at src/java/org/apache/cassandra/cql3/statements/schema/AlterTypeStatement.java:259

        }
    }

    private static final class AlterField extends AlterTypeStatement
    {
        private AlterField(String keyspaceName, String typeName, boolean ifExists)
        {
            super(keyspaceName, typeName, ifExists);
        }

        @Override
        public boolean compatibleWith(ClusterMetadata metadata)
        {
            return metadata.directory.commonSerializationVersion.isAtLeast(Version.V0);
        }

        UserType apply(KeyspaceMetadata keyspace, UserType userType)
        {
            throw ire("Altering field types is no longer supported");
        }
    }

    public static final class Raw extends CQLStatement.Raw
    {
        private enum Kind
        {
            ADD_FIELD, RENAME_FIELDS, ALTER_FIELD
        }

        private final UTName name;
        private final boolean ifExists;
        private boolean ifFieldExists;
        private boolean ifFieldNotExists;

        private Kind kind;

        // ADD

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Remove the ALTER TYPE ... ALTER statement; Cassandra no longer supports changing field types
2. Create a new UDT with the desired field types and a new column (or migrate via a new table), then drop the old one
3. Add a new field with the new type and migrate data via application-level reads/writes, then remove the old field if acceptable
4. Audit schema-migration scripts and guard them to fail fast on unsupported ALTER TYPE ALTER operations

Example fix

// before
ALTER TYPE address ALTER zip TYPE int;

// after
CREATE TYPE address_v2 (street text, zip int);
-- migrate data, then swap the column and drop the old type

// Check the DDL before executing
if (/\bALTER\s+TYPE\s+\S+\s+ALTER\b/i.test(cql)) {
  throw new Error('ALTER TYPE field-type changes are unsupported; create a new UDT instead');
}

function isAlterTypeFieldChange(stmt) {
  return /^ALTER\s+TYPE\s+\S+\s+ALTER\b/i.test(stmt.trim());
}

try {
  session.execute("ALTER TYPE address ALTER zip TYPE int");
} catch (e) {
  if (e.code === 8704 || /Altering field types is no longer supported/.test(e.message)) {
    // fall back to create-new-UDT migration path
  } else throw e;
}

When it happens

Trigger: Executing `ALTER TYPE <keyspace>.<type> ALTER <field> TYPE <newtype>` — the statement's kind is an AlterFieldType alteration, which is dispatched to apply() and always throws.

Common situations: Scripts ported from older Cassandra versions that relied on ALTER TYPE ... ALTER; schema migration tooling generating field type changes; developers renaming/refactoring UDT field types after deployment.

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

• Not enough bytes to read size of %dth field %s
• Not enough bytes to read %dth field %s
• Invalid operation (%s) for non-UDT column %s
• Invalid operation (%s) for frozen UDT column %s
• UDT column %s does not have a field named %s

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/e9d200c3b0ee15cb. Report an issue: GitHub.