cassandra-commits mailing list archives

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

    [ https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188078#comment-13188078
] 

Eric Evans commented on CASSANDRA-3634:
---------------------------------------

bq. Perhaps it is a JDBC specific problem but often, tooling will use setInt() if it is a
number to be stored in a string column and more frequently a setString() for an integer field.
The concern is the PreparedStatement suite of methods provides a lot of flexibility to do
these kinds of implied transformations that will be difficult without cooperation between
the client and server. to do on the client side only, will require knowing the entire potential
schema cached on the client side.

I think I see what you're saying and this just falls under the "strings are easier argument".
 You're able to get away with more because it's the server that's doing the marshaling for
you.  For example, it doesn't matter whether the schema is Int32, Integer, Long, etc, as long
as you pass something that vaguely looks like a number, it'll do the Right Thing.

With binary arguments you will need to keep a client-side copy of the schema so that you know
how to encode each argument (like Thrift clients have been doing for some time).

So if a user calls {{setString("10")}} where schema is LongType, you'll need to first create
a long from the string, and then marshal it to bytes for the request.

Validation is also something that you're going to need to do client-side; I don't think there
is any validation that the server can do that it isn't already.  For example, with numeric
types, other than validating the length of the {{byte[]}} (think Long or Int32), there really
aren't any  bytes that would be _invalid_.


                
> compare string vs. binary prepared statement parameters
> -------------------------------------------------------
>
>                 Key: CASSANDRA-3634
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3634
>             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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message