cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12909) cqlsh copy cannot parse strings when counters are present
Date Tue, 20 Dec 2016 03:02:58 GMT


Stefania commented on CASSANDRA-12909:

Protectors are used more widely than converters for non-prepared statements, converters are
only applied to partition keys to determine the routing, protectors to all values.

The call to {{unicode}} in {{_get_protector}} was added by CASSANDRA-11850 when we upgraded
the driver to 3.5. Five tests were failing with Unicode conversion problems without it, but
I cannot recall which ones and the original test results for 11850 have been deleted. So I
don't know if the call to {{unicode}} can be moved to the converters. I am repeating the tests
for the 2.2 patch above without a {{unicode}} call in the protectors.  

> cqlsh copy cannot parse strings when counters are present
> ---------------------------------------------------------
>                 Key: CASSANDRA-12909
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Stefania
>            Assignee: Stefania
>             Fix For: 2.2.x, 3.0.x, 3.x
> We get parse error {{Failed to import 1 rows: ParseError - argument for 's' must be a
string}} when using the following table and data:
> {code}
> CREATE TABLE ks.test (
>     object_id ascii,
>     user_id timeuuid,
>     counter_id ascii,
>     count counter,
>     PRIMARY KEY ((object_id, user_id), counter_id)
> )
> {code}
> {code}
> EVT:be3bd2d0-a68d-11e6-90d4-1b2a65b8a28a,f7ce3ac0-a66e-11e6-b58e-4e29450fd577,SA,2
> {code}
> The problem is this line [here|],
strings are serialized as unicode rather than ordinary strings but only for non-prepared statements
(unsure why).

This message was sent by Atlassian JIRA

View raw message