关于Cassandra Duration类型返回不一致及相关类型问题的技术问询

环境与复现场景 #

在Cassandra 4.0.5中创建数据表：

create table duration_table
(
    id           int primary key,
    duration_col duration
);

使用4.6.4版本的Cassandra Node.js驱动时，出现以下差异现象：

• 调用client.metadata.getTable(keyspaceName, "duration_table")获取表元数据时，duration_col的类型code为21，对应驱动枚举types.dataTypes.duration；
• 执行client.execute("SELECT * FROM duration_table")查询后，该列的类型code为0，对应types.dataTypes.custom枚举，且info字段值为org.apache.cassandra.db.marshal.DurationType。

技术疑问与解答 #

1. 同一列为何在元数据查询与数据查询中返回的类型不一致？ #

这是因为Cassandra的系统表元数据读取逻辑和查询结果的协议层编码逻辑存在差异：

• 元数据查询（getTable）直接读取system_schema.columns等系统表的类型定义，Duration作为Cassandra 4.x新增的原生类型，在这里已经被正确映射为对应code（21）；
• 而查询结果的类型编码基于Cassandra协议的序列化规则，在该驱动版本与Cassandra版本的适配逻辑中，Duration类型在结果集返回时仍被当作自定义类型处理，驱动通过info字段中的类全名来识别具体类型。这属于驱动与数据库版本协议适配的过渡性问题，后续驱动迭代可能会统一两者的类型返回逻辑。

2. ResultSet中org.apache.cassandra.db.marshal.DurationType这个info值是否始终存在？能否作为Duration类型的常量标识？ #

• 在当前Cassandra 4.x + Node.js驱动4.x的组合下，这个info值会始终存在，因为Cassandra底层确实通过DurationType类处理该类型的序列化与反序列化；
• 可以将该值作为Duration列类型的常量标识，因为Cassandra原生类型对应的marshal类全名是固定的，不会随意变更。建议做双重兼容判断：优先检查类型code是否为21，若为custom类型（code=0）再校验info字段是否匹配该类名，避免后续驱动更新统一类型code后出现判断失效的情况。

3. 还有哪些Cassandra原生类型会被驱动返回为custom类型？ #

在驱动与Cassandra版本适配不完整的场景下，以下原生类型可能被识别为custom类型：

• date：早期版本中可能对应org.apache.cassandra.db.marshal.SimpleDateType；
• time：对应org.apache.cassandra.db.marshal.TimeType；
• 用户定义类型（UDT）：驱动会将其标记为custom类型，info字段为UDT的类全名；
• tuple类型：早期协议版本中可能被当作custom类型处理。

这类情况大多出现在驱动与Cassandra版本跨度过大的场景，随着驱动迭代更新，原生类型的协议映射会逐步完善，被识别为custom的情况会逐步减少。

内容的提问来源于stack exchange，提问作者Liberator