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 queries, and doesn't have a wide library of built-in functions. I'd be a supporter of more BIFs, and that's a solvable problem. String size, collection size, timestamp conversions, etc. could all be useful, even though there's not much gained over doing them in the client. With constraints only being applied during write coordination, there's not much of an advantage over implementing the equivalent constraints in clients. Writes that don't include all columns could violate multi-column constraints, like your (a > b) example, for the same reason as CASSANDRA-19007 <https://issues.apache.org/jira/browse/CASSANDRA-19007>. Constraints could be limited to only apply to frozen columns, where it's known that the entire value will be updated at once. I don't think we should include any constraints where valid user action would lead to a violated constraint, like permitting multi-column constraints on regular columns or non-frozen types, since they would be too prone to mis-use. Regarding 19007, it could be useful to have a constraint that indicates that a subset of columns will always be updated together, since that would actually allow Cassandra to know which read queries are safe, and permit a fix for 19007 that minimizes the additional data replicas need to send to coordinators on ALLOW FILTERING queries. That's a very specific situation and shouldn't justify a new framework / API, but might be a useful consequence of it. > - isJson (is the text a json?) Wouldn't it be more compelling to have a new type, analogous to the Postgres JSONB type? https://www.postgresql.org/docs/current/datatype-json.html If we're going to parse the entire JSON blob for validation, we might as well store it in an optimized format, support better access patterns, etc.
