Cassandra Wire Protocol中'duration'类型的ProtocolID及JDBC扩展问题

Let's tackle your two core questions head-on, plus share actionable advice tailored to your project's urgent constraints:

1. Is there an existing branch of the cassandra-jdbc-wrapper with Duration type support? #

From what I know of the original adejanovski/cassandra-jdbc-wrapper project and its community forks, there is no publicly maintained branch that adds explicit Duration type support. The original project has been stagnant for years, targeting Java 1.6 and older Cassandra/Driver versions—long before the Duration type was introduced in Cassandra 3.11 and DataStax Driver 3.7+.

Given your situation (already forked the project, upgraded to Driver 3.8.0, urgent customer needs, and incompatible commercial solutions), your best path is to implement the Duration support yourself in your fork rather than waiting for an existing branch to appear.

2. What is the Protocol ID for the Duration type, and where is it defined? #

The Duration type's wire protocol ID (protocol code) is 22 (hex 0x16). Here's where you can confirm this:

In DataStax Java Driver 3.x #

While the driver uses enums instead of exposing raw protocol IDs directly, you can retrieve the code programmatically with this one-liner:

int durationProtocolId = DataType.Name.DURATION.getProtocolCode();

Under the hood, this value is hardcoded in the DataType.Name enum's constructor for DURATION in the driver's source code.

In Cassandra Core Code #

On the Cassandra side, the Duration type's protocol ID is defined in org.apache.cassandra.db.marshal.DurationType, where it registers itself with the protocol code 22 during initialization.

Actionable Implementation Steps for Your Fork #

Since you've already started modifying the DataTypeEnum in com.github.adejanovski.cassandra.jdbc, here's how to complete the Duration support:

1. Update your DataTypeEnum:
   Fix the DURATION entry with the correct protocol ID and matching Java type (use java.time.Duration for modern compatibility, or adjust if your JDBC layer expects a different type):

   DURATION (22, java.time.Duration.class, DataType.Name.DURATION)
   

2. Add a TypeCodec for Duration:
   You'll need to implement a codec to handle serialization/deserialization between Cassandra's Duration wire format and Java's Duration class. Create a class extending AbstractTypeCodec<Duration>:

   public class DurationCodec extends AbstractTypeCodec<Duration> {
       public DurationCodec() {
           super(DataType.Name.DURATION, Duration.class);
       }
   
       @Override
       public ByteBuffer serialize(Duration value, ProtocolVersion protocolVersion) throws InvalidTypeException {
           // Implement serialization: convert Java Duration to Cassandra's wire format (4-byte months, 8-byte days, 8-byte nanoseconds)
       }
   
       @Override
       public Duration deserialize(ByteBuffer bytes, ProtocolVersion protocolVersion) throws InvalidTypeException {
           // Implement deserialization: parse Cassandra's wire format back to Java Duration
       }
   
       @Override
       public String format(Duration value) throws InvalidTypeException {
           return value.toString();
       }
   
       @Override
       public Duration parse(String value) throws InvalidTypeException {
           return Duration.parse(value);
       }
   }
   

3. Register the codec in your JDBC wrapper:
   Ensure your wrapper's codec registry picks up the new DurationCodec, following the same pattern used for other existing codecs.

Why Skip the Instrumentation Approach? #

Your idea of using instrumentation to capture "unknown codec" info is clever, but it's error-prone because:

• It relies on runtime exceptions which can behave unpredictably across driver versions
• It doesn't solve the core serialization/deserialization problem—you still need a codec to properly handle the type
• It adds unnecessary complexity to your codebase, which is risky for an urgent customer request

Sticking to the explicit protocol ID and codec implementation is the far more reliable path.

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