cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Grundman (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1688) Enhance cassandra-cli with more flexible querying and better data type support
Date Tue, 08 Feb 2011 19:29:57 GMT

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

Andy Grundman commented on CASSANDRA-1688:
------------------------------------------

Some more info: If I do set Users[119][id] = 119; in the CLI, the value is then printed correctly.

The 3223865 value is coming from another app setting the value over Thrift. Reading the data
back out with Thrift does return 119, though. I'm getting the feeling this may need to be
a new bug.

> Enhance cassandra-cli with more flexible querying and better data type support
> ------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-1688
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1688
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Tools
>            Reporter: Jim Ancona
>         Attachments: cli-enhanced-get.patch
>
>
> In trying to use cassandra-cli, I've felt the need to have better support for non-String
data types, and more flexibility in the types of queries possible. The attached patch is an
attempt to address some of those issues. 
> It enhances the GET command with a more flexible syntax, outlined below. The new syntax
adds to and partially duplicates the current GET syntax, but is more verbose. Functionally
it's a superset of the LIST command, but I haven't removed any functionality yet. I added
support for the Thrift getSlice and getRangeSlices calls.
> Syntax overview:
> getSlice examples:
> {noformat}
> get CF2 key Long(12345) columns from 10000 to 99999999999
> get SCF1 supercolumn 'super' key 'hello' columns 'world' as integer, 'moon' as ascii,

> {noformat}
> getRangeSlices examples:
> {noformat}
> get CF2 keys all columns from 10000 to 99999999999
> get SCF1 supercolumn 'super' keys from Integer(1234567876) limit 500 columns 'world'
as integer
> get CF2 keys from 'A' to 'Z' columns from 10000 to 99999999999 limit 50
> {noformat}
> Pseudo-Antlr syntax
> {noformat}
> thriftGetSlice
>     : K_GET columnParent 'KEY' keyValue columnSlice?
> thriftGetRangeSlices
>     : K_GET columnParent keyRange? columnSlice?
> columnParent
>     : columnFamily ('SUPERCOLUMN' superColumnName)?
> columnSlice
>     : (columnList | columnRange | allColumns)
>  
> columnList
>     : 'COLUMNS' columnSpec (',' columnSpec)*
>  
> columnRange
>     : 'COLUMNS' ('FROM' startColumn)? ('TO' endColumn)? ('AS' typeIdentifier)? ('LIMIT'
limit)?
>     
> allColumns
>     : 'COLUMNS' 'ALL' ('AS' typeIdentifier)? ('LIMIT' limit)?
> keyRange
>     : 'KEYS' ( ('FROM' startKeyValue)? ('TO' endKeyValue)? |  ALL ) ('LIMIT' limit=IntegerLiteral)?
> columnSpec
>     : columnName ('AS' typeIdentifier)?
> value: (Identifier | IntegerLiteral | StringLiteral | functionCall );
> functionCall 
>     : functionName=Identifier '(' functionArgument ')'
> {noformat}
> Questions:
> * Should I use a different keyword? Perhaps GET should be reserved for the simple bracket-based,
single-key case and this functionality should use LIST or SELECT as a keyword.
> * Should the syntax be more SQL-like? I started out doing that, but it seemed to me that
the C* model is so different that mapping it to the SQL syntax was difficult. I haven't looked
at Eric Evans' CQL work in any detail yet, but perhaps that is a better model.
> Additional work:
> * The KEYS and COLUMNS keywords should be added to the GET / WHERE syntax for getIndexedSlices.
> * The LIST command should be deprecated or removed.
> * The SET command should be enhanced to allow for non-string keys and column names.
> * I've used a different model for processing the syntax tree in the code. If other people
like it, it would make sense to convert the rest of CliClient to the same model.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message