cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Shaw (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2475) Prepared statements
Date Wed, 29 Jun 2011 18:08:30 GMT


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:
>             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:


View raw message