[
https://issues.apache.org/jira/browse/CASSANDRA-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246269#comment-13246269
]
Rick Shaw commented on CASSANDRA-4001:
--------------------------------------
Note that this problem will need to have an effective solution in order for the
parameterized AbstractType to be used in a similar way for Maps, Sets and
Lists. Perhaps an optional map : {{map<binary,string> baseclass}} argument to
{{CqlMetadata}}?
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
