Thanks a lot for your comments Abe!
I do agree that the Constraint clause should be as simple as possible. I will
add a note on the CEP along with some specifics about the proposed constraints
(removing the ones that are contentious, and adding them to a possible future
additions section). And yeah, I also think that these constraints will help
different Cassandra operating paradigms (multi-tenant clusters and diverse
workflows).
Besides that, I hope that I’ve addressed all the potential concerns and
feedback on the thread. Let’s let a bit more time for others to chime in (any
further feedback will be more than welcome), but I’d like to move forward with
a voting soon if no other concerns are pointed out.
All and all, thanks a lot to everyone that participated in the thread and added
to the discussion!
Bernardo
> On Jun 12, 2024, at 2:37 PM, Abe Ratnofsky <a...@aber.io> wrote:
>
> I've thought about this some more. It would be useful for Cassandra to
> support user-defined "guardrails" (or constraints, whatever you want to call
> them), that could be applied per keyspace or table. Whether a user or an
> operator is considered the owner of a table depends on the organization
> deploying Cassandra, so allowing both parties to protect their tables against
> mis-use seems good to me, especially for large multi-tenant clusters with
> diverse workloads.
>
> For example, it would be really useful if a user could set the
> Guardrails.{read,write}ConsistencyLevels for their tables, or declare whether
> all operations should be over LWTs to avoid mixing regular and LWT workloads.
>
> I'm hesitant about adding lots of expression syntax to the CONSTRAINT clause.
> I think I'd prefer a function calling syntax that represents:
> 1. Whether the constraint is system / keyspace / table scoped
> 2. Where in query processing the constraint is checked
> 3. What is executed by the check
