cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4001) CqlMetadata can't represent parametrized comparators
Date Tue, 06 Mar 2012 09:56:58 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223129#comment-13223129
] 

Sylvain Lebresne commented on CASSANDRA-4001:
---------------------------------------------

bq. should the CqlMetadata.default_name_type include the parentheses and the parameters used

Note that AbstractType has a toString() that correctly includes parentheses and parameters
(this is used by CFMetatada when serializing/deserializing the schema). It would be rather
easy to actually use that for CQL too. Though it places slightly more burden on the client
side to parse those.
                
> 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

        

Mime
View raw message