You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The consistency level given when preparing a PreparedStatement has no immediate effect. All that happens is that the given consistency-level value is saved in the PreparedStatement Java object - and only later when the prepared statement is bound into a BoundStatement, this saved consistency-level is inherited by the new object, and when the bound statement it is executed, the consistency level is sent via the CQL protocol. So far so good.
@michoecho discovered a case where a user was using a batch statement with a prepared statement in it, something like
BatchStatementBuilder batchStatementBuilder = new BatchStatementBuilder(BatchType.LOGGED);
batchStatementBuilder.addStatement(myPreparedStatement.bind(...));
The problem is that a batch statement has its own consistency level setting, and only that setting is sent to the server (CQL only allows one consistency setting per statement - even if it's a batch). The consistency level variable set in myPreparedStatement and copied to the bind() output is outright ignored!
Note how confusing this is - the user may think that he created a prepared statement with QUORUM consistency, but when when inserting it into a batch statement, it ends up executed using the batch statement's default consistency level which is usually ONE, resulting in incorrect consistency!
I think BatchStatementBuilder should check if any of the of the statements added by addStatement() has a different (or just higher?) consistency level requirement than it itself has, and if that situation is detected, the request should produce a run-time warning, or even run-time error and not run at all.
I don't know if we have a similar problem also in drivers of other languages :-(
The text was updated successfully, but these errors were encountered:
Our documentation of
PreparedStatement
(see https://java-driver.docs.scylladb.com/stable/manual/core/statements/prepared/) doesn't explain too clearly what theConsistencyLevel
options does (Datastax's documentation, https://docs.datastax.com/en/drivers/java/2.1/com/datastax/driver/core/PreparedStatement.html, is clearer), but to make a long story short:The consistency level given when preparing a PreparedStatement has no immediate effect. All that happens is that the given consistency-level value is saved in the PreparedStatement Java object - and only later when the prepared statement is bound into a BoundStatement, this saved consistency-level is inherited by the new object, and when the bound statement it is executed, the consistency level is sent via the CQL protocol. So far so good.
@michoecho discovered a case where a user was using a batch statement with a prepared statement in it, something like
The problem is that a batch statement has its own consistency level setting, and only that setting is sent to the server (CQL only allows one consistency setting per statement - even if it's a batch). The consistency level variable set in myPreparedStatement and copied to the bind() output is outright ignored!
Note how confusing this is - the user may think that he created a prepared statement with QUORUM consistency, but when when inserting it into a batch statement, it ends up executed using the batch statement's default consistency level which is usually ONE, resulting in incorrect consistency!
I think BatchStatementBuilder should check if any of the of the statements added by
addStatement()
has a different (or just higher?) consistency level requirement than it itself has, and if that situation is detected, the request should produce a run-time warning, or even run-time error and not run at all.I don't know if we have a similar problem also in drivers of other languages :-(
The text was updated successfully, but these errors were encountered: