Add support for Duration type

[Ponewor]

Fixes: #320

This works great with Scylla but for some reason it fails with Cassandra (at least with 4.0.1). The column type code that Cassandra is sending for Duration is 0 instead of 0x15 and it is followed with type's name: "org.apache.cassandra.db.marshal.DurationType". How should we deal with it?

Apart from that (and a few missing tests or docstrings), is there anything serious missing here?

Pre-review checklist

• I have split my patch into logically separate commits.
• All commit messages clearly explain what they change and why.
• I added relevant tests for new features and bug fixes.
• All commits compile, pass static checks and pass test.
• PR description sums up the changes and reasons why they should be introduced.
• I added appropriate Fixes: annotations to PR description.

[psarna]

@Ponewor I have no idea why Cassandra decided to encode duration as a custom type instead of a native type, but it is legal in CQL v4. Here's an excerpt from https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v4.spec:

The option for <type> is either a native
          type (see below), in which case the option has no value, or a
          'custom' type, in which case the value is a [string] representing
          the fully qualified class name of the type represented. Valid option
          ids are:
            0x0000    Custom: the value is a [string], see above.
            0x0001    Ascii
            0x0002    Bigint
            0x0003    Blob
            (...)

So this is actually a mild compatibility bug - not a serious one, because our driver should be free to not recognize specific custom types, but perhaps we should have a map of handlers for a few known ones - e.g. org.apache.cassandra.db.marshal.DurationType.

I created #364 to track the problem. For now, either make the test optional or add a Cassandra-specific bypass - namely, let the test pass either when it returns a correct duration, or when it fails because it received a custom type. If you decide to go with the latter, please also add a comment about it in the test case.

[piodul]

@Ponewor The Duration type was introduced in v5 of the CQL protocol. There was a need for this type to be supported in Scylla - however, Scylla only supports v4 so the support for it was backported to the older version of the protocol.

If you look at the protocol specifications as defined in the Cassandra repository, you can see that in v4 there is no concept of Duration (see here), it is only introduced in v5 (here).

In order to be compatible with the protocol v4, I guess that Cassandra decides to encode Durations as a "Custom" type. I'm not aware of how the encoding looks, though. I agree with @psarna on how to handle this for Cassandra.

[piodul]

The other drivers (Gocql and the Datastax Java Driver) seem to calculate this in a clever, branchless way - look here.

[piodul]

It would be good to check that the decoded i64's do not overflow.

[psarna]

@Ponewor The Duration type was introduced in v5 of the CQL protocol. There was a need for this type to be supported in Scylla - however, Scylla only supports v4 so the support for it was backported to the older version of the protocol.

Ah, makes sense. Btw, we could consider allowing the user to declare the version explicitly to allow "version spoofing". That would allow users to set v5 here, e.g. if they know that they'll only use the subset of v5 that's actually implemented. It would act as a trivial workaround for issues like this.

If you look at the protocol specifications as defined in the Cassandra repository, you can see that in v4 there is no concept of Duration (see here), it is only introduced in v5 (here).

In order to be compatible with the protocol v4, I guess that Cassandra decides to encode Durations as a "Custom" type. I'm not aware of how the encoding looks, though. I agree with @psarna on how to handle this for Cassandra.

[psarna]

any updates on this one?