[
https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166318#comment-13166318
]
Eric Evans commented on CASSANDRA-2475:
---------------------------------------
{quote}
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.
{quote}
Believe it or not, between ASCII strings and hex encoded blobs, the latter is
cheaper to decode node-side.
{quote}
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.
{quote}
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.
OK
{quote}
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.
{quote}
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: https://issues.apache.org/jira/browse/CASSANDRA-2475
> 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,
> v1-0002-regenerated-thrift-java.txt
>
>
--
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
