[
https://issues.apache.org/jira/browse/CASSANDRA-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992141#comment-12992141
]
Pavel Yaskevich commented on CASSANDRA-1688:
--------------------------------------------
Branch trunk (latest commit 804729f1ee53c8314b7415f36924c772c4d48bf0)
CLI session:
{code}
[default@unknown] create keyspace ks1;
19b893f0-33bc-11e0-0000-242d50ca1fbe
[default@unknown] use ks1;
Authenticated to keyspace: ks1
[default@ks1] create column family Users with comparator=AsciiType and
column_metadata=[{column_name:id, validation_class:IntegerType}];
19b893f0-33bc-11e0-0000-242d50cf1fbe
default@ks1] set Users[119][id] = 119;
Value inserted.
[default@ks1] list Users;
Using default limit of 100
-------------------
RowKey: 119
=> (column=id, value=119, timestamp=1297194393696000)
1 Row Returned.
[default@ks1] get Users[119];
=> (column=id, value=119, timestamp=1297194393696000)
Returned 1 results.
default@ks1] get Users[119] as IntegerType;
=> (column=id, value=119, timestamp=1297194393696000)
Returned 1 results.
[default@ks1] describe keyspace;
eyspace: ks1:
Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Replication Factor: 1
Column Families:
ColumnFamily: Users
Columns sorted by: org.apache.cassandra.db.marshal.AsciiType
Row cache size / save period: 0.0/0
Key cache size / save period: 200000.0/3600
Memtable thresholds: 0.29062499999999997/62/60
GC grace seconds: 864000
Compaction min/max thresholds: 4/32
Read repair chance: 1.0
Built indexes: []
Column Metadata:
Column Name: id (id)
Validation Class: org.apache.cassandra.db.marshal.IntegerType
{code}
Restarting CLI and doing `list Users;`, `get Users[119];`, `get Users[119] as
IntegerType;` gives the same _right_ result.
> 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
