[jira] [Updated] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-8754: Labels: LWT ponies (was: ponies) > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla >Priority: Major > Labels: LWT, ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users 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 (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[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)
[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. For example we can specify that all queries should be at least CL LOCAL_QUORUM. 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: 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. 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. For example we can specify that all queries should be at least CL LOCAL_QUORUM. 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)
[jira] [Updated] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-8754: Description: Idea is to prevent a query based on a consistency level not being met. For example we can specify that all queries should be at least CL LOCAL_QUORUM. Lots of users 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: Idea is to prevent a query based on a consistency level not being met. For example we can specify that all queries should be at least CL LOCAL_QUORUM. 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. For example we can specify that all queries should be at least CL LOCAL_QUORUM. Lots of users 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)
[jira] [Updated] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-8754: Labels: ponies (was: ) Required consistency level -- Key: CASSANDRA-8754 URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 Project: Cassandra Issue Type: New Feature Reporter: Ryan Svihla Labels: ponies Idea is to prevent a query based on a consistency level not being met. For example we can specify that all queries should be at least CL LOCAL_QUORUM. Lots of users 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)
