You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ryan Svihla (JIRA)" <ji...@apache.org> on 2015/02/06 18:38:34 UTC
[jira] [Updated] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan Svihla updated CASSANDRA-8754:
-----------------------------------
Description:
Idea is to prevent a query based on a consistency level not being met.
Lots of customers struggle with getting all their dev teams on board with consistency levels and all the ramifications. The normal solution for this has traditionally to build a service in front of Cassandra that the entire dev team accesses. However, this has proven challenging for some organizations to do correctly, and I think an easier approach would be to require a given consistency level as a matter of enforced policy in the database.
I'm open for where this belongs. The most flexible approach is at a table level, however I'm concerned this is potentially error prone and labor intensive. It could be a table attribute similar to compaction strategy.
The simplest administratively is a cluster level, in say the cassandra.yaml
The middle ground is at they keyspace level, the only downside I could foresee is keyspace explosion to fit involved minimum schemes. It could be a keyspace attribute such as replication strategy.
was:
Based on restrictions prevent a query based on a query level not being met.
Lots of customers struggle with getting all their dev teams on board with consistency levels and all the ramifications. The normal solution for this has traditionally to build a service in front of Cassandra that the entire dev team accesses. However, this has proven challenging for some organizations to do correctly, and I think an easier approach would be to require a given consistency level as a matter of enforced policy in the database.
I'm open for where this belongs. The most flexible approach is at a table level, however I'm concerned this is potentially error prone and labor intensive. It could be a table attribute similar to compaction strategy.
The simplest administratively is a cluster level, in say the cassandra.yaml
The middle ground is at they keyspace level, the only downside I could foresee is keyspace explosion to fit involved minimum schemes. It could be a keyspace attribute such as replication strategy.
> Required consistency level
> --------------------------
>
> Key: CASSANDRA-8754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8754
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Ryan Svihla
>
> Idea is to prevent a query based on a consistency level not being met.
> Lots of customers struggle with getting all their dev teams on board with consistency levels and all the ramifications. The normal solution for this has traditionally to build a service in front of Cassandra that the entire dev team accesses. However, this has proven challenging for some organizations to do correctly, and I think an easier approach would be to require a given consistency level as a matter of enforced policy in the database.
> I'm open for where this belongs. The most flexible approach is at a table level, however I'm concerned this is potentially error prone and labor intensive. It could be a table attribute similar to compaction strategy.
> The simplest administratively is a cluster level, in say the cassandra.yaml
> The middle ground is at they keyspace level, the only downside I could foresee is keyspace explosion to fit involved minimum schemes. It could be a keyspace attribute such as replication strategy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)