[jira] [Updated] (CASSANDRA-4734) Move CQL3 consistency to protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4734: Attachment: 0003-Thrift-generated-file-diffs-3.txt 0002-Remove-remains-of-4448-3.txt 0001-Move-consistency-level-to-the-protocol-level-3.txt bq. I really think the right thing to do here is leave it out until we have a better understanding of the use cases involved Ok, I buy that. Attaching v3 with 4448 removed. Move CQL3 consistency to protocol - Key: CASSANDRA-4734 URL: https://issues.apache.org/jira/browse/CASSANDRA-4734 Project: Cassandra Issue Type: Task Components: API Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Fix For: 1.2.0 beta 2 Attachments: 0001-Move-consistency-level-to-the-protocol-level-2.txt, 0001-Move-consistency-level-to-the-protocol-level-3.txt, 0001-Move-consistency-level-to-the-protocol-level.txt, 0002-Remove-remains-of-4448-3.txt, 0002-Remove-remains-of-4448.txt, 0002-Thrift-generated-file-diffs-2.txt, 0003-Thrift-generated-file-diffs-3.txt, 0003-Thrift-generated-file-diffs.txt Currently, in CQL3, you set the consistency level of an operation in the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'. It now looks like this was a mistake, and that consistency should be set at the protocol level, i.e. as a separate parameter along with the query. The reasoning is that the CL applies to the guarantee provided by the operation being successful, not to the query itself. Specifically, having the CL being part of the language means that CL is opaque to low level client libraries without themselves parsing the CQL, which we want to avoid. Thus, - Those libraries can't implement automatic retries policy, where a query would be retried with a smaller CL. (I'm aware that this is often a Bad Idea, but it does have legitimate uses and not having that available is seen as a regression from the Thrift api.) - We had to introduce CASSANDRA-4448 to allow the client to configure some form of default CL since the library can't handle that anymore, which is hackish. - Executing prepared statements with different CL requires preparing multiple statements. - CL only makes sense for BATCH operations as a whole, not the sub-statements within the batch. Currently CQL3 fixes that by validating the given CLs match, but it would be much more clear if the CL was on the protocol side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4734) Move CQL3 consistency to protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4734: Attachment: 0002-Thrift-generated-file-diffs-2.txt 0001-Move-consistency-level-to-the-protocol-level-2.txt The patches needed some rebasing, but after reflexion, I also think that we should keep CASSANDRA-4448 even with that. I think the most of the arguments in that issue still hold even if we move the consistency to the protocol level. So v2 attached keep that feature. Move CQL3 consistency to protocol - Key: CASSANDRA-4734 URL: https://issues.apache.org/jira/browse/CASSANDRA-4734 Project: Cassandra Issue Type: Task Components: API Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Fix For: 1.2.0 beta 2 Attachments: 0001-Move-consistency-level-to-the-protocol-level-2.txt, 0001-Move-consistency-level-to-the-protocol-level.txt, 0002-Remove-remains-of-4448.txt, 0002-Thrift-generated-file-diffs-2.txt, 0003-Thrift-generated-file-diffs.txt Currently, in CQL3, you set the consistency level of an operation in the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'. It now looks like this was a mistake, and that consistency should be set at the protocol level, i.e. as a separate parameter along with the query. The reasoning is that the CL applies to the guarantee provided by the operation being successful, not to the query itself. Specifically, having the CL being part of the language means that CL is opaque to low level client libraries without themselves parsing the CQL, which we want to avoid. Thus, - Those libraries can't implement automatic retries policy, where a query would be retried with a smaller CL. (I'm aware that this is often a Bad Idea, but it does have legitimate uses and not having that available is seen as a regression from the Thrift api.) - We had to introduce CASSANDRA-4448 to allow the client to configure some form of default CL since the library can't handle that anymore, which is hackish. - Executing prepared statements with different CL requires preparing multiple statements. - CL only makes sense for BATCH operations as a whole, not the sub-statements within the batch. Currently CQL3 fixes that by validating the given CLs match, but it would be much more clear if the CL was on the protocol side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4734) Move CQL3 consistency to protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4734: Attachment: (was: 0001-Move-consistency-level-to-the-protocol-level-2.txt) Move CQL3 consistency to protocol - Key: CASSANDRA-4734 URL: https://issues.apache.org/jira/browse/CASSANDRA-4734 Project: Cassandra Issue Type: Task Components: API Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Fix For: 1.2.0 beta 2 Attachments: 0001-Move-consistency-level-to-the-protocol-level.txt, 0002-Remove-remains-of-4448.txt, 0002-Thrift-generated-file-diffs-2.txt, 0003-Thrift-generated-file-diffs.txt Currently, in CQL3, you set the consistency level of an operation in the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'. It now looks like this was a mistake, and that consistency should be set at the protocol level, i.e. as a separate parameter along with the query. The reasoning is that the CL applies to the guarantee provided by the operation being successful, not to the query itself. Specifically, having the CL being part of the language means that CL is opaque to low level client libraries without themselves parsing the CQL, which we want to avoid. Thus, - Those libraries can't implement automatic retries policy, where a query would be retried with a smaller CL. (I'm aware that this is often a Bad Idea, but it does have legitimate uses and not having that available is seen as a regression from the Thrift api.) - We had to introduce CASSANDRA-4448 to allow the client to configure some form of default CL since the library can't handle that anymore, which is hackish. - Executing prepared statements with different CL requires preparing multiple statements. - CL only makes sense for BATCH operations as a whole, not the sub-statements within the batch. Currently CQL3 fixes that by validating the given CLs match, but it would be much more clear if the CL was on the protocol side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4734) Move CQL3 consistency to protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4734: Attachment: 0001-Move-consistency-level-to-the-protocol-level-2.txt (I've updated my v2 to keep the current behavior of the default CL concerning batches) Move CQL3 consistency to protocol - Key: CASSANDRA-4734 URL: https://issues.apache.org/jira/browse/CASSANDRA-4734 Project: Cassandra Issue Type: Task Components: API Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Fix For: 1.2.0 beta 2 Attachments: 0001-Move-consistency-level-to-the-protocol-level-2.txt, 0001-Move-consistency-level-to-the-protocol-level.txt, 0002-Remove-remains-of-4448.txt, 0002-Thrift-generated-file-diffs-2.txt, 0003-Thrift-generated-file-diffs.txt Currently, in CQL3, you set the consistency level of an operation in the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'. It now looks like this was a mistake, and that consistency should be set at the protocol level, i.e. as a separate parameter along with the query. The reasoning is that the CL applies to the guarantee provided by the operation being successful, not to the query itself. Specifically, having the CL being part of the language means that CL is opaque to low level client libraries without themselves parsing the CQL, which we want to avoid. Thus, - Those libraries can't implement automatic retries policy, where a query would be retried with a smaller CL. (I'm aware that this is often a Bad Idea, but it does have legitimate uses and not having that available is seen as a regression from the Thrift api.) - We had to introduce CASSANDRA-4448 to allow the client to configure some form of default CL since the library can't handle that anymore, which is hackish. - Executing prepared statements with different CL requires preparing multiple statements. - CL only makes sense for BATCH operations as a whole, not the sub-statements within the batch. Currently CQL3 fixes that by validating the given CLs match, but it would be much more clear if the CL was on the protocol side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4734) Move CQL3 consistency to protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4734: Attachment: (was: 0001-Move-consistency-level-to-the-protocol-level.txt) Move CQL3 consistency to protocol - Key: CASSANDRA-4734 URL: https://issues.apache.org/jira/browse/CASSANDRA-4734 Project: Cassandra Issue Type: Task Components: API Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Fix For: 1.2.0 beta 2 Attachments: 0001-Move-consistency-level-to-the-protocol-level.txt, 0002-Remove-remains-of-4448.txt, 0003-Thrift-generated-file-diffs.txt Currently, in CQL3, you set the consistency level of an operation in the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'. It now looks like this was a mistake, and that consistency should be set at the protocol level, i.e. as a separate parameter along with the query. The reasoning is that the CL applies to the guarantee provided by the operation being successful, not to the query itself. Specifically, having the CL being part of the language means that CL is opaque to low level client libraries without themselves parsing the CQL, which we want to avoid. Thus, - Those libraries can't implement automatic retries policy, where a query would be retried with a smaller CL. (I'm aware that this is often a Bad Idea, but it does have legitimate uses and not having that available is seen as a regression from the Thrift api.) - We had to introduce CASSANDRA-4448 to allow the client to configure some form of default CL since the library can't handle that anymore, which is hackish. - Executing prepared statements with different CL requires preparing multiple statements. - CL only makes sense for BATCH operations as a whole, not the sub-statements within the batch. Currently CQL3 fixes that by validating the given CLs match, but it would be much more clear if the CL was on the protocol side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4734) Move CQL3 consistency to protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4734: Attachment: (was: 0002-Remove-remains-of-4448.txt) Move CQL3 consistency to protocol - Key: CASSANDRA-4734 URL: https://issues.apache.org/jira/browse/CASSANDRA-4734 Project: Cassandra Issue Type: Task Components: API Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Fix For: 1.2.0 beta 2 Attachments: 0001-Move-consistency-level-to-the-protocol-level.txt, 0002-Remove-remains-of-4448.txt, 0003-Thrift-generated-file-diffs.txt Currently, in CQL3, you set the consistency level of an operation in the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'. It now looks like this was a mistake, and that consistency should be set at the protocol level, i.e. as a separate parameter along with the query. The reasoning is that the CL applies to the guarantee provided by the operation being successful, not to the query itself. Specifically, having the CL being part of the language means that CL is opaque to low level client libraries without themselves parsing the CQL, which we want to avoid. Thus, - Those libraries can't implement automatic retries policy, where a query would be retried with a smaller CL. (I'm aware that this is often a Bad Idea, but it does have legitimate uses and not having that available is seen as a regression from the Thrift api.) - We had to introduce CASSANDRA-4448 to allow the client to configure some form of default CL since the library can't handle that anymore, which is hackish. - Executing prepared statements with different CL requires preparing multiple statements. - CL only makes sense for BATCH operations as a whole, not the sub-statements within the batch. Currently CQL3 fixes that by validating the given CLs match, but it would be much more clear if the CL was on the protocol side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4734) Move CQL3 consistency to protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4734: Attachment: 0003-Thrift-generated-file-diffs.txt 0002-Remove-remains-of-4448.txt 0001-Move-consistency-level-to-the-protocol-level.txt Slightly updated patch that adds a pepare_cql3_query and deprecate set_cql_version (it's kept however so as to not break compatibility, but it's now a no-op). Move CQL3 consistency to protocol - Key: CASSANDRA-4734 URL: https://issues.apache.org/jira/browse/CASSANDRA-4734 Project: Cassandra Issue Type: Task Components: API Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Fix For: 1.2.0 beta 2 Attachments: 0001-Move-consistency-level-to-the-protocol-level.txt, 0002-Remove-remains-of-4448.txt, 0003-Thrift-generated-file-diffs.txt Currently, in CQL3, you set the consistency level of an operation in the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'. It now looks like this was a mistake, and that consistency should be set at the protocol level, i.e. as a separate parameter along with the query. The reasoning is that the CL applies to the guarantee provided by the operation being successful, not to the query itself. Specifically, having the CL being part of the language means that CL is opaque to low level client libraries without themselves parsing the CQL, which we want to avoid. Thus, - Those libraries can't implement automatic retries policy, where a query would be retried with a smaller CL. (I'm aware that this is often a Bad Idea, but it does have legitimate uses and not having that available is seen as a regression from the Thrift api.) - We had to introduce CASSANDRA-4448 to allow the client to configure some form of default CL since the library can't handle that anymore, which is hackish. - Executing prepared statements with different CL requires preparing multiple statements. - CL only makes sense for BATCH operations as a whole, not the sub-statements within the batch. Currently CQL3 fixes that by validating the given CLs match, but it would be much more clear if the CL was on the protocol side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4734) Move CQL3 consistency to protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4734: Attachment: 0002-Remove-remains-of-4448.txt 0001-Move-consistency-level-to-the-protocol-level.txt Attaching patches to do that. There is the question of thrift. The current patch choses to introduce two new, CQL3 only, execute_cql3_query and execute_prepared_cql3_query methods and start refusing CQL3 queries in the old methods. This may or may not be what we want to do, and even if it is, we probably can do some cleanups if we start separating the calls for CQL2 and CQL3. Move CQL3 consistency to protocol - Key: CASSANDRA-4734 URL: https://issues.apache.org/jira/browse/CASSANDRA-4734 Project: Cassandra Issue Type: Task Components: API Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Fix For: 1.2.0 beta 2 Attachments: 0001-Move-consistency-level-to-the-protocol-level.txt, 0002-Remove-remains-of-4448.txt Currently, in CQL3, you set the consistency level of an operation in the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'. It now looks like this was a mistake, and that consistency should be set at the protocol level, i.e. as a separate parameter along with the query. The reasoning is that the CL applies to the guarantee provided by the operation being successful, not to the query itself. Specifically, having the CL being part of the language means that CL is opaque to low level client libraries without themselves parsing the CQL, which we want to avoid. Thus, - Those libraries can't implement automatic retries policy, where a query would be retried with a smaller CL. (I'm aware that this is often a Bad Idea, but it does have legitimate uses and not having that available is seen as a regression from the Thrift api.) - We had to introduce CASSANDRA-4448 to allow the client to configure some form of default CL since the library can't handle that anymore, which is hackish. - Executing prepared statements with different CL requires preparing multiple statements. - CL only makes sense for BATCH operations as a whole, not the sub-statements within the batch. Currently CQL3 fixes that by validating the given CLs match, but it would be much more clear if the CL was on the protocol side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4734) Move CQL3 consistency to protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4734: -- Description: Currently, in CQL3, you set the consistency level of an operation in the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'. It now looks like this was a mistake, and that consistency should be set at the protocol level, i.e. as a separate parameter along with the query. The reasoning is that the CL applies to the guarantee provided by the operation being successful, not to the query itself. Specifically, having the CL being part of the language means that CL is opaque to low level client libraries without themselves parsing the CQL, which we want to avoid. Thus, - Those libraries can't implement automatic retries policy, where a query would be retried with a smaller CL. (I'm aware that this is often a Bad Idea, but it does have legitimate uses and not having that available is seen as a regression from the Thrift api.) - We had to introduce CASSANDRA-4448 to allow the client to configure some form of default CL since the library can't handle that anymore, which is hackish. - Executing prepared statements with different CL requires preparing multiple statements. - CL only makes sense for BATCH operations as a whole, not the sub-statements within the batch. Currently CQL3 fixes that by validating the given CLs match, but it would be much more clear if the CL was on the protocol side. Move CQL3 consistency to protocol - Key: CASSANDRA-4734 URL: https://issues.apache.org/jira/browse/CASSANDRA-4734 Project: Cassandra Issue Type: Task Components: API Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Fix For: 1.2.0 beta 2 Currently, in CQL3, you set the consistency level of an operation in the language, eg 'SELECT * FROM foo USING CONSISTENCY QUORUM'. It now looks like this was a mistake, and that consistency should be set at the protocol level, i.e. as a separate parameter along with the query. The reasoning is that the CL applies to the guarantee provided by the operation being successful, not to the query itself. Specifically, having the CL being part of the language means that CL is opaque to low level client libraries without themselves parsing the CQL, which we want to avoid. Thus, - Those libraries can't implement automatic retries policy, where a query would be retried with a smaller CL. (I'm aware that this is often a Bad Idea, but it does have legitimate uses and not having that available is seen as a regression from the Thrift api.) - We had to introduce CASSANDRA-4448 to allow the client to configure some form of default CL since the library can't handle that anymore, which is hackish. - Executing prepared statements with different CL requires preparing multiple statements. - CL only makes sense for BATCH operations as a whole, not the sub-statements within the batch. Currently CQL3 fixes that by validating the given CLs match, but it would be much more clear if the CL was on the protocol side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
