Re: [DISCUSS] LWT conditions behavior on collections is inconsistent (CASSANDRA-19637)

2024-06-12 Thread Ekaterina Dimitrova
Hey Benjamin, Thanks for the fix and raising the point here. The patch seems reasonable to me. The only thing to confirm on my mind is whether people consider it behavior breaking change or only a bug fix. Based on that we can move forward with patch for 4.0+ or only trunk. It will be also good t

Re: [DISCUSS] CEP-42: Constraints Framework

2024-06-12 Thread Abe Ratnofsky
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 dep

Re: [DISCUSS] CEP-42: Constraints Framework

2024-06-12 Thread Jon Haddad
I think having JSON validation on existing text fields is a pretty reasonable idea, regardless if we have a JSON type or not. I could see folks wanting to add a JSON constraint to an existing text field, for example. I like the idea of a postgres-style JSONB type, but I don't want to derail this

Re: [Discuss] CEP-24 Password validation and generation

2024-06-12 Thread Bernardo Botella
+1 on Francisco’s comments. TCM is a general feature that a lot of other things will benefit from, and the fact that this CEP is one of those that will benefit shouldn’t block it from moving forward. > On Jun 11, 2024, at 11:16 PM, Francisco Guerrero wrote: > > Stefan, thanks for moving this C

Re: [DISCUSS] CEP-42: Constraints Framework

2024-06-12 Thread Abe Ratnofsky
Hey Bernardo, Thanks for the proposal and putting together your summary of the discussion. A few thoughts: I'm not completely convinced of the value of CONSTRAINTS for a database like Cassandra, which doesn't support any referential integrity checks, doesn't do read-before-write for all querie

Re: [DISCUSS] CEP-42: Constraints Framework

2024-06-12 Thread Bernardo Botella
Hi again, I completely agree that anything beyond simple poses a problem. My point is that the definition of simple may vary, and each of those constraints I mentioned deserves a conversation on its own. As I previously mentioned on the dev thread: https://lists.apache.org/thread/qln8cbkhlw9j95

Re: [DISCUSS] CEP-42: Constraints Framework

2024-06-12 Thread Štefan Miklošovič
My gut feeling is that anything beyond simple comparisons is just too problematic / complex. I think that this should be part of the application logic rather than putting that to the database. Is there any major database out there which has constraints modelled like that? (belongsToEnum, isNotBlock

Re: [DISCUSS] CEP-42: Constraints Framework

2024-06-12 Thread Claude Warren, Jr via dev
> > 2) > Is part of an enum is somehow suplying the lack of enum types. Constraint > could be something like CONSTRAINT belongsToEnum([list of valid values], > field): > CREATE TABLE keyspace.table ( > field text CONSTRAINT belongsToEnum(['foo', 'foo2'], field), > ... > ); > 3) > Similarly, we