[ https://issues.apache.org/jira/browse/CASSANDRA-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
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: https://issues.apache.org/jira/browse/CASSANDRA-4001 > 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} > CREATE COLUMNFAMILY paramcompar (KEY text PRIMARY KEY) > 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: http://www.atlassian.com/software/jira