Correct decoding for Trino UUID partition key value

[findinpath]

Fixes #10799

[findinpath]

I've skipped (in this initial commit) on purpose adding the typedecimal field to the composed primary key because the test is failing. Apparently in Cassandra 2.2 when comparing 128.0 with 128 there is no match found.

[ebyhr]

Could you file an issue and leave as code comment?

[findinpath]

I created #10927 and referenced it in the new test.

[findinpath]

TestCassandraConnectorTest tests on Cassandra 2.2.
However the code has the following logic

https://github.com/trinodb/trino/blob/master/plugin/trino-cassandra/src/main/java/io/trino/plugin/cassandra/CassandraSession.java#L369-L376

for retrieving the partitions.

Any advice on how could we cover the usecase of dealing with Cassandra 2.2+ ?

[ebyhr]

Not sure if I understood your question correctly, but the image name 2.2 gets the latest 2.2.x (=2.2.19 today). The comparison (2.2.19 compareTo 2.2 > 0) will return true.

[findinpath]

Sorry for the confusion.

I was wondering how do we get to test the else branch.

            log.debug("Using combination of partition values to fetch partitions.");
            rows = queryPartitionKeysLegacyWithMultipleQueries(table, filterPrefixes);

[ebyhr]

We can get the coverage by running tests on Cassandra 2.1. It will require some refactoring of tests though.

[ebyhr]

Please separate into two commits because other types are unrelates to the bug fix

1. Correct decoding for Trino UUID partition key value + only UUID test
2. Add other types to the test

[ebyhr]

We can get the coverage by running tests on Cassandra 2.1. It will require some refactoring of tests though.

[ebyhr]

Merged, thanks!

[relistan]

Awesome @findinpath @ebyhr Thanks!