cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Resolved] (CASSANDRA-4001) CqlMetadata can't represent parametrized comparators
Date Tue, 25 Sep 2012 09:19:08 GMT


Sylvain Lebresne resolved CASSANDRA-4001.

    Resolution: Duplicate

CASSANDRA-4453 has solved this by making it so that we return the full name of the AbstractType
(including eventual parameters) instead of just the name of the class.
> CqlMetadata can't represent parametrized comparators
> ----------------------------------------------------
>                 Key: CASSANDRA-4001
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: API
>    Affects Versions: 1.0.0
>            Reporter: paul cannon
>            Priority: Minor
>              Labels: cql, cqlsh
> When a CF is created with a parametrized comparator, e.g.
> {noformat}
> CREATE COLUMNFAMILY paramcompar (KEY text PRIMARY KEY) WITH comparator='TimeUUIDType(reversed=true)';
> {noformat}
> or, equivalently:
> {noformat}
>   WITH comparator='ReversedType(org.apache.cassandra.db.marshal.TimeUUIDType)';
> {noformat}
> and then a CQL query is made against any populated contents, the resulting CqlMetadata
part of the response only conveys that the "{{default_name_type='ReversedType'}}". This is
not very helpful to a CQL library in decoding the column name. At least in the case of python-cql,
it falls back on assuming UTF8Type as a default, which almost invariably leads to errors since
the bytes in most UUIDs do not represent valid utf8 bytes.
> I'm not sure what the right solution is; should the CqlMetadata.default_name_type include
the parentheses and the parameters used (requiring CQL libraries to be able to interpret arbitrary
parameterized types, or at least the more straightforward ones), or should CQL libraries need
to query for CfDefs through Thrift and interpret comparator_type, or should CqlMetadata.default_name_type
only convey enough information for valid deserialization (in this case, just TimeUUIDType
would have worked)? Possibly that last might require adding some sort of special interface
to classes implementing AbstractType. Not at all clear how that would work with CompositeType
values, although maybe we can punt on that with the direct cql3 syntactical support.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message