cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Shaw (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3634) compare string vs. binary prepared statement parameters
Date Tue, 17 Jan 2012 19:33:39 GMT


Rick Shaw commented on CASSANDRA-3634:

Well I assume the err will be thrown if the server can discern that an error exists but without
additional info there is no way to know it is not compatible outside of the verify() method
in {{AbstractType}}. The problem is (or mooter? :) ) if String is the mechanism of transfer.

I don't see any ambiguity in String? Each method pushes a string ({{toString()?}} or custom
encoding) representation; so as long as {{fromString()}} on the validator can handle without
exception then most variations will work. It will stumble on things like passing "xyz" to
a numeric data type, but that is reported gracefully as a conversion exception to numeric.

My point has always been that IF we choose passing {{ByteBuffer}} then the server side would
only benefit from knowing how the data was encoded in terms of checking for errors and enhanced
ability to transform data to the  required type. I'll do what it takes on the client side
either way.

> compare string vs. binary prepared statement parameters
> -------------------------------------------------------
>                 Key: CASSANDRA-3634
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: API, Core
>            Reporter: Eric Evans
>            Assignee: Eric Evans
>            Priority: Minor
>              Labels: cql
>             Fix For: 1.1
> Perform benchmarks to compare the performance of string and pre-serialized binary parameters
to prepared statements.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message