[jira] [Created] (CASSANDRA-7018) cqlsh failing to handle utf8 decode errors in certain cases
Colin B. created CASSANDRA-7018:
---
Summary: cqlsh failing to handle utf8 decode errors in certain
cases
Key: CASSANDRA-7018
URL: https://issues.apache.org/jira/browse/CASSANDRA-7018
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: Colin B.
Priority: Minor
Under certain circumstances when a row to be returned in cqlsh contains a utf8
decoding error, no results will be printed. It seems that certain types of
where clauses cause the decoding to fail.
Preparation:
{code}
[cqlsh 3.1.8 | Cassandra 1.2.16 | CQL spec 3.0.0 | Thrift protocol 19.36.2]
...
cqlsh:ks CREATE TABLE test_utf8 ( a text PRIMARY KEY, b text );
cqlsh:ks INSERT INTO test_utf8 (a, b) VALUES (blobAsText(0x3031f6393130),
'0110');
cqlsh:ks select * from test_utf8;
a | b
-+--
'01\xf6910' | 0110
Failed to decode value '01\xf6910' (for column 'a') as text: 'utf8' codec can't
decode byte 0xf6 in position 2: invalid start byte
cqlsh:ks
{code}
Actual Results:
{code}
cqlsh:ks select * from test_utf8 where a = blobAsText(0x3031f6393130);
value '01\xf6910' (in col 'a') can't be deserialized as text: 'utf8' codec
can't decode byte 0xf6 in position 2: invalid start byte
cqlsh:ks
{code}
Expected Results:
{code}
cqlsh:ks select * from test_utf8 where a = blobAsText(0x3031f6393130);
a | b
-+--
'01\xf6910' | 0110
Failed to decode value '01\xf6910' (for column 'a') as text: 'utf8' codec can't
decode byte 0xf6 in position 2: invalid start byte
cqlsh:ks
{code}
Traceback with cqlsh --debug:
{code}
cqlsh:ks select * from test_utf8 where a = blobAsText(0x3031f6393130);
Traceback (most recent call last):
File bin/cqlsh, line 942, in onecmd
self.handle_statement(st, statementtext)
File bin/cqlsh, line 982, in handle_statement
return self.handle_parse_error(cmdword, tokens, parsed, srcstr)
File bin/cqlsh, line 991, in handle_parse_error
return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
File bin/cqlsh, line 1031, in perform_statement
with_default_limit=with_default_limit)
File bin/cqlsh, line 1059, in perform_statement_untraced
self.print_result(self.cursor, with_default_limit)
File bin/cqlsh, line , in print_result
self.print_static_result(cursor)
File bin/cqlsh, line 1141, in print_static_result
formatted_values = [map(self.myformat_value, self.decode_row(cursor, row),
cursor.column_types) for row in cursor.result]
File bin/cqlsh, line 590, in decode_row
values.append(cursor.decoder.decode_value(val, vtype, nameinfo[0]))
File bin/../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/decoders.py, line
54, in decode_value
vtype.cql_parameterized_type())
File bin/../lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/decoders.py, line
33, in value_decode_error
% (valuebytes, namebytes, expectedtype, err))
ProgrammingError: value '01\xf6910' (in col 'a') can't be deserialized as text:
'utf8' codec can't decode byte 0xf6 in position 2: invalid start byte
cqlsh:ks
{code}
Problematic statements:
{code}
cqlsh:ks select * from test_utf8 where token(a) 0;
cqlsh:ks select * from test_utf8 where a in (blobAsText(0x3031f6393130));
cqlsh:ks select * from test_utf8 where a = blobAsText(0x3031f6393130);
{code}
Statements that are ok:
{code}
cqlsh:ks select * from test_utf8 where token(a) token('qwer');
cqlsh:ks select * from test_utf8;
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CASSANDRA-5713) CQL3 token() = token() does not work as expected
Colin B. created CASSANDRA-5713:
---
Summary: CQL3 token() = token() does not work as expected
Key: CASSANDRA-5713
URL: https://issues.apache.org/jira/browse/CASSANDRA-5713
Project: Cassandra
Issue Type: Bug
Reporter: Colin B.
Priority: Minor
Using tokens to go backward through a table in CQL3 does not work as expected.
Say there is some data available:
{code}
SELECT key FROM data_list where token(key) = token('6') limit 10;
key
-
6
7
9
4
3
A
5
8
2
1
{code}
I expect:
{code}
SELECT key FROM data_list where token(key) = token('1') limit 5;
key
-
A
5
8
2
1
{code}
However the following occurs:
{code}
SELECT key FROM data_list where token(key) = token('1') limit 5;
key
-
6
7
9
4
3
{code}
The '' operator has similar unexpected behavior.
--
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
[jira] [Commented] (CASSANDRA-4775) Counters 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13693681#comment-13693681 ] Colin B. commented on CASSANDRA-4775: - Would anyone be interested in a type of counter that is about 99% correct, but not exact? The Hyperloglog cardinality estimation algorithm would be fairly straight forward to implement inside Cassandra. It estimates the number of distinct elements in a set. One way to use it as a counter is to have a two sets of timeuuids, A and R. Each time you want to increment the counter add a timeuuid to the A set, each time you want to decrement add a timeuuid to the R set. Count is the count in A minus the count in R. Re-adding the same item (timeuuid) to a set is idempotent. A read would need to access a constant amount of internal data and the internal data is a good fit for Cassandra's method of merging distributed writes. A description of the Hyperloglog algorithm is available here: http://blog.aggregateknowledge.com/2012/10/25/sketch-of-the-day-hyperloglog-cornerstone-of-a-big-data-infrastructure/ Counters 2.0 Key: CASSANDRA-4775 URL: https://issues.apache.org/jira/browse/CASSANDRA-4775 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Arya Goudarzi Assignee: Aleksey Yeschenko Labels: counters Fix For: 2.1 The existing partitioned counters remain a source of frustration for most users almost two years after being introduced. The remaining problems are inherent in the design, not something that can be fixed given enough time/eyeballs. Ideally a solution would give us - similar performance - less special cases in the code - potential for a retry mechanism -- 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
[jira] [Updated] (CASSANDRA-4421) Support cql3 table definitions in Hadoop InputFormat
[
https://issues.apache.org/jira/browse/CASSANDRA-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin B. updated CASSANDRA-4421:
Attachment: 4421-8-cb.txt
Attached is patch 4421-8-cb containing the changes from jbellis's branch. It
applies onto cassandra-1.2 cleanly (11eb352).
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.6
Attachments: 4421-1.txt, 4421-2.txt, 4421-3.txt, 4421-4.txt,
4421-5.txt, 4421-6.cb.txt, 4421-6-je.txt, 4421-7-je.txt, 4421-8-cb.txt,
4421.txt
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
[jira] [Updated] (CASSANDRA-4421) Support cql3 table definitions in Hadoop InputFormat
[
https://issues.apache.org/jira/browse/CASSANDRA-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin B. updated CASSANDRA-4421:
Attachment: (was: 4421-8-cb.txt)
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.6
Attachments: 4421-1.txt, 4421-2.txt, 4421-3.txt, 4421-4.txt,
4421-5.txt, 4421-6.cb.txt, 4421-6-je.txt, 4421-7-je.txt, 4421-8-cb.txt,
4421.txt
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
[jira] [Updated] (CASSANDRA-4421) Support cql3 table definitions in Hadoop InputFormat
[
https://issues.apache.org/jira/browse/CASSANDRA-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin B. updated CASSANDRA-4421:
Attachment: 4421-8-cb.txt
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.6
Attachments: 4421-1.txt, 4421-2.txt, 4421-3.txt, 4421-4.txt,
4421-5.txt, 4421-6.cb.txt, 4421-6-je.txt, 4421-7-je.txt, 4421-8-cb.txt,
4421.txt
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
[jira] [Updated] (CASSANDRA-4421) Support cql3 table definitions in Hadoop InputFormat
[
https://issues.apache.org/jira/browse/CASSANDRA-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin B. updated CASSANDRA-4421:
Attachment: 4421-6.cb.txt
If any cares, attached is 4421-6.cb.txt which is the 4421-5 patch on top of
commit 2f72f8b in cassandra-1.2
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.6
Attachments: 4421-1.txt, 4421-2.txt, 4421-3.txt, 4421-4.txt,
4421-5.txt, 4421-6.cb.txt, 4421.txt
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
[jira] [Comment Edited] (CASSANDRA-4421) Support cql3 table definitions in Hadoop InputFormat
[
https://issues.apache.org/jira/browse/CASSANDRA-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671074#comment-13671074
]
Colin B. edited comment on CASSANDRA-4421 at 5/31/13 2:36 AM:
--
If anyone cares, attached is 4421-6.cb.txt which is the 4421-5 patch on top of
commit 2f72f8b in cassandra-1.2
was (Author: lanzaa):
If any cares, attached is 4421-6.cb.txt which is the 4421-5 patch on top of
commit 2f72f8b in cassandra-1.2
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.6
Attachments: 4421-1.txt, 4421-2.txt, 4421-3.txt, 4421-4.txt,
4421-5.txt, 4421-6.cb.txt, 4421.txt
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
[jira] [Commented] (CASSANDRA-4421) Support cql3 table definitions in Hadoop InputFormat
[
https://issues.apache.org/jira/browse/CASSANDRA-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671179#comment-13671179
]
Colin B. commented on CASSANDRA-4421:
-
Obviously your new patch is better than mine. The major differences between the
two are:
* you seem to have left out the example code
* the ClientHolder stuff, which you don't seem to include in your patch
* fix conflicts with CASSANDRA-5536
* fix conflicts with CASSANDRA-5529
The conflict resolution is the only difficulty I noticed while putting the
patch onto the head of cassandra-1.2 . Overall not a big deal.
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.6
Attachments: 4421-1.txt, 4421-2.txt, 4421-3.txt, 4421-4.txt,
4421-5.txt, 4421-6.cb.txt, 4421-6-je.txt, 4421.txt
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
[jira] [Comment Edited] (CASSANDRA-4421) Support cql3 table definitions in Hadoop InputFormat
[
https://issues.apache.org/jira/browse/CASSANDRA-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671179#comment-13671179
]
Colin B. edited comment on CASSANDRA-4421 at 5/31/13 5:28 AM:
--
Obviously your new patch is better than mine. The major differences between the
two are:
* lots of little formatting changes, 4421-6-je is better here
* 4421-6-je seems to leave out the example code
* the ClientHolder stuff, which 4421-6-je doesn't include
* fix conflicts with CASSANDRA-5536
* fix conflicts with CASSANDRA-5529
The conflict resolution is the only difficulty I noticed while putting the
patch onto the head of cassandra-1.2 . Overall not a big deal.
was (Author: lanzaa):
Obviously your new patch is better than mine. The major differences between
the two are:
* you seem to have left out the example code
* the ClientHolder stuff, which you don't seem to include in your patch
* fix conflicts with CASSANDRA-5536
* fix conflicts with CASSANDRA-5529
The conflict resolution is the only difficulty I noticed while putting the
patch onto the head of cassandra-1.2 . Overall not a big deal.
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.6
Attachments: 4421-1.txt, 4421-2.txt, 4421-3.txt, 4421-4.txt,
4421-5.txt, 4421-6.cb.txt, 4421-6-je.txt, 4421.txt
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
