[
https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14312035#comment-14312035
]
Sylvain Lebresne commented on CASSANDRA-8754:
---------------------------------------------
bq. The biggest benefit would be to enforce sanity on LWT operations not mixing
with non-LWT
It's a good point, which does imply we need to separate reads and writes as
non-LWT reads often make sense on LWT updated tables.
bq. Alternatively, we could use the capability-limitation framework that we've
discussed before, if that feels like a better fit
Actually, it kind of does sound like capabillity limitation, and the framework
we've discussed so far (CASSANDRA-8303) is per-table and distinguish reads and
writes, both of which are desirable. It further adds the notion of roles which
kind of make sense for this too. Further, said framework might be extended
someday to include things like having default limitations for newly created
tables, and this would also benefit to this feature. Overall, this is the
option that makes the most sense to me (adding it as table options is simple
but feels a bit more adhoc to me).
> 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)
