[
https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309625#comment-14309625
]
Ryan Svihla commented on CASSANDRA-8754:
----------------------------------------
Also in regards to the ponying of this. It may help to understand the all too
common situation I have to help people with. Education of CL doesn't spread
across diverse dev teams accessing the same cluster, and worse turnover is
often high. So all new code has the potential to invalidate company policy. If
we have some artifact that is reviewable in Cassandra, I can be certain quickly
the issue isn't in them misunderstanding of what a Consistency Level is..or
some rogue users logging in and doing stuff by hand.
If we're just relying on code, I have to comb through all code that touches the
database sever, and I have to be able to read said code, trust I've seen said
code to be able to diagnose "the data isn't consistent problems". This can take
an enormous amount of time, when reviewing say a schema file would take 2
minutes.
> 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)
