You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "paul cannon (Created) (JIRA)" <ji...@apache.org> on 2012/03/05 18:43:59 UTC

[jira] [Created] (CASSANDRA-4001) CqlMetadata can't represent parametrized comparators

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


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

[jira] [Commented] (CASSANDRA-4001) CqlMetadata can't represent parametrized comparators

Posted by "Rick Shaw (Commented) (JIRA)" <ji...@apache.org>.
    [ 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

[jira] [Commented] (CASSANDRA-4001) CqlMetadata can't represent parametrized comparators

Posted by "Sylvain Lebresne (Commented) (JIRA)" <ji...@apache.org>.
    [ 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

[jira] [Resolved] (CASSANDRA-4001) CqlMetadata can't represent parametrized comparators

Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
     [ 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