cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Evans (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2475) Prepared statements
Date Fri, 09 Dec 2011 17:13:40 GMT


Eric Evans commented on CASSANDRA-2475:

But then I hated the idea of having to go to HEX to get in "blob"/bytes data. This approach
let me do both. It also allowed me to serialize Java Objects nicely as bytes. Can you think
of a clever way to handle byte streams (AbstractBytes)? But I can live with just String. I
agree it is the most flexible.

Believe it or not, between ASCII strings and hex encoded blobs, the latter is cheaper to decode

It allows you to free the cached {{CQLStatement}} on the server side when a client side PreparedStatement
is closed. If not, you will accumulate dead entries until the connection is closed. That could
be a lot of dead wood. Seemed the tidy thing to do.

So, my initial thought (and what led me to ask this), was that in practice, the number of
prepared statements per active connection is probably quite low.  Low enough that there would
never be any reason to evict.  You probably wouldn't want to bet the farm on that though,
so I had thought it would probably make some sense to have a threshold that would cause statements
to be evicted when new ones were added (on an LRU-basis).

This seems to have the advantage that would make the interface simpler.  It would also be
less error prone; Relying on the client to free resources seems a bit brittle.

What do you think?

bq. The count is to know how many markers were actually encountered. This number serves as
the upper bound for Setxxx parameter indexes. Better than regexing for it... it is exactly
what the server side encountered.


The statement type is again a validation of what the server side saw. Remember this happens
in 2 steps prepare then execute, and the execute step does not have the CQL text.
But I used it while debugging and I don't seem to use it any more so I guess it could go,
but it I thought I might find a use for is so I never did make it go away.

It's probably best to avoid without a raison d'etre.  Things like this are easier to add later,
than they are to remove once they've made it into release.

bq. Another "seems useful" so I kept it around. If something goes wrong and you need to go
poking around its handy to have attached to the statement (I think).

I worry that it might be wasteful.  Especially if we do need to worry about the number of
statements we keep for each connection.

Query logging can be used to capture the verbatim string for troubleshooting purposes, and
all of the data should still be there in the form of the graph of objects.  Is there some
known case that doesn't cover?

bq. I think there was already an instance there at DEBUG and I just added some more. I'll
gladly move to TRACE.

The way it was originally, the statement type (SELECT, UPDATE, etc) was logged at level DEBUG,
and the entire query was logged at TRACE.  If there isn't a reason to change, we should probably
keep it that way.

bq. The short answer is because the question marks  are often referred to in the spec as "bound
variable markers". So I just propagated it. But NBD to change to "bind" theme.

OK. Yeah, even say {{indexBindMarkers}} would be good.  I was just thinking that "markers"
was a bit generic there.
> Prepared statements
> -------------------
>                 Key: CASSANDRA-2475
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>    Affects Versions: 1.0.5
>            Reporter: Eric Evans
>            Assignee: Rick Shaw
>            Priority: Minor
>              Labels: cql
>             Fix For: 1.1
>         Attachments: 2475-v1.patch, 2475-v2.patch, v1-0001-CASSANDRA-2475-prepared-statement-patch.txt,

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