[
https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057375#comment-13057375
]
Rick Shaw commented on CASSANDRA-2475:
--------------------------------------
I guess I was a bit too vague... My suggestion would be to return the
pre-parsed token stream not something you would re-parse every time it is
re-submitted. It is the same item I think you suggest we cache on the server
side. I think the interesting twist is that using the suggested method the
pre-parsed item (or "prepared" statement) could be used days later in a
different connection. It would be an immutable resource. If it is cached server
side it is only good for the connection life.
But its just a suggestion. I understand the merits of retaining complete
control of the format over time and the efficiencies by passing the "handle"
back and forth. And I was not familiar with the ClientState at all.
More troubling is the batch semantics... I hate the idea of disrupting the
current syntax in CQL but I think the parameter substitution step will be very
fragile if there is not a notion of lists of items that are tightly coupled
with their respective handle's parameters in the batch. The thought of
thousands of rows worth of entries in a batch and getting the parameters right
for a giant array/list of parameters that fill into the pre-compiled tokens
seems fraught with problems. How does the repeating nature get expressed?
Currently it is very concrete and can be parsed into a mutation on the fly. But
if it is pre-parsed what syntax represents the concept of repetition? Is the
syntax different for the prepared statement vs. the simple (not prepared)
statement as today?
The crafters of the JDBC driver specification seemed to have been faced with
the same problem. Their solution was to have a "batch" method as well as
"execute" methods that takes an array/list of prepared statements. Unsolved for
us is how to recognize the notion of "mutation start"/"Mutation end" using that
approach. Maybe you just do a "prepare" call for "BEGIN BATCH" and "APPLY
BATCH" and use them in the list sent via the "batch" method?
> Prepared statements
> -------------------
>
> Key: CASSANDRA-2475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2475
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
> Reporter: Eric Evans
> Labels: cql
> Fix For: 1.0
>
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
