[ https://issues.apache.org/jira/browse/CASSANDRA-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647673#comment-13647673 ]
Alex Liu edited comment on CASSANDRA-4421 at 5/2/13 4:31 PM: ------------------------------------------------------------- There are no auto paging for CQL3, so I use a work around method to page through CQL wide rows. Basic idea is to use CQL3 query on the partition key and cluster columns {code} e.g. PRIMARY(m, n , o, p) where partition key is m, cluster columns are n, o, p {code} for Query {code} Select * from test limit 1000; {code} We store the last values of m, n, o, p to m_end, n_end, O_end and p_end after the initial 1000 rows so the next page query is {code} Select * from test where token(m) = token (m_end) and n = n_end and o = o_end and p > p_end Limit 1000 {code} If it reach the end of O, then the next query is the following query {code} Select * from test where token(m) = toekn(m_end) and n = n_end and o > o_end Limit 1000 {code} otherwise {code} Select * from test where token(m) = token (m_end) and n = n_end and o = o_end and p > p_end1 Limit 1000 {code} until it reach to the next row, the query is {code} Select * from test where token(m) > token(m_end) Limit 1000 {code} For the table has more than one columns in partition key {code} PRIMARY((m, n) , o, p) where partition key is m and n, cluster columns are o, p {code} we use the following query {code} Select * from test where token(m, n) > token(m_end, n_end) Limit 1000 {code} was (Author: alexliu68): There are no auto paging for CQL3, so it's hard to use a work around method to page through CQL wide rows. Basic idea is to use CQL3 query on the partition key and cluster columns {code} e.g. PRIMARY(m, n , o, p) where partition key is m, cluster columns are n, o, p {code} for Query {code} Select * from test limit 1000; {code} We store the last values of m, n, o, p to m_end, n_end, O_end and p_end after the initial 1000 rows so the next page query is {code} Select * from test where token(m) = token (m_end) and n = n_end and o = o_end and p > p_end Limit 1000 {code} If it reach the end of O, then the next query is the following query {code} Select * from test where token(m) = toekn(m_end) and n = n_end and o > o_end Limit 1000 {code} otherwise {code} Select * from test where token(m) = token (m_end) and n = n_end and o = o_end and p > p_end1 Limit 1000 {code} until it reach to the next row, the query is {code} Select * from test where token(m) > token(m_end) Limit 1000 {code} For the table has more than one columns in partition key {code} PRIMARY((m, n) , o, p) where partition key is m and n, cluster columns are o, p {code} we use the following query {code} Select * from test where token(m, n) > token(m_end, n_end) Limit 1000 {code} > Support cql3 table definitions in Hadoop InputFormat > ---------------------------------------------------- > > Key: CASSANDRA-4421 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4421 > Project: Cassandra > Issue Type: Improvement > Components: API > Affects Versions: 1.1.0 > Environment: Debian Squeeze > Reporter: bert Passek > Labels: cql3 > Fix For: 1.2.5 > > > Hello, > i faced a bug while writing composite column values and following validation > on server side. > This is the setup for reproduction: > 1. create a keyspace > create keyspace test with strategy_class = 'SimpleStrategy' and > strategy_options:replication_factor = 1; > 2. create a cf via cql (3.0) > create table test1 ( > a int, > b int, > c int, > primary key (a, b) > ); > If i have a look at the schema in cli i noticed that there is no column > metadata for columns not part of primary key. > create column family test1 > with column_type = 'Standard' > and comparator = > 'CompositeType(org.apache.cassandra.db.marshal.Int32Type,org.apache.cassandra.db.marshal.UTF8Type)' > and default_validation_class = 'UTF8Type' > and key_validation_class = 'Int32Type' > and read_repair_chance = 0.1 > and dclocal_read_repair_chance = 0.0 > and gc_grace = 864000 > and min_compaction_threshold = 4 > and max_compaction_threshold = 32 > and replicate_on_write = true > and compaction_strategy = > 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' > and caching = 'KEYS_ONLY' > and compression_options = {'sstable_compression' : > 'org.apache.cassandra.io.compress.SnappyCompressor'}; > Please notice the default validation class: UTF8Type > Now i would like to insert value > 127 via cassandra client (no cql, part of > mr-jobs). Have a look at the attachement. > Batch mutate fails: > InvalidRequestException(why:(String didn't validate.) [test][test1][1:c] > failed validation) > A validator for column value is fetched in > ThriftValidation::validateColumnData which returns always the default > validator which is UTF8Type as described above (The ColumnDefinition for > given column name "c" is always null) > In UTF8Type there is a check for > if (b > 127) > return false; > Anyway, maybe i'm doing something wrong, but i used cql 3.0 for table > creation. I assigned data types to all columns, but i can not set values for > a composite column because the default validation class is used. > I think the schema should know the correct validator even for composite > columns. The usage of the default validation class does not make sense. > Best Regards > Bert Passek -- 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