Thanks everyone for the inputs. Dinesh: "constraint should not violate the max bound of the guardrail” -> Yes, that statement is true with the proposed patch. With code as is, the write will fail if it either does not comply with the guardrail OR does not comply with the constraint. The CEP touched this as well, stating that guardrails take preference over defined constraints in schemas, so no matter what, these guardrails will always be respected.
Thanks, Bernardo > On Feb 8, 2025, at 6:09 PM, Dinesh Joshi <djo...@apache.org> wrote: > > Guardrails and constraints serve distinct purposes. Guardrails allow the > operator to define reasonable bounds while constraints allow the developer to > do the same in the schema. However the constraint should not violate the max > bound of the guardrail. For example, if an operator defines the max size of a > column to be 1MiB then a constraint in the schema cannot go beyond this max > size limit. This allows the operator to define reasonable limits while > allowing the developer control over their application’s limits. > > On Sat, Feb 8, 2025 at 12:03 PM Bernardo Botella > <conta...@bernardobotella.com <mailto:conta...@bernardobotella.com>> wrote: >> Hi everyone, >> >> After Constraints framework was merged in, I would like to come back to the >> discussion Jordan brought up in this Jira: >> https://issues.apache.org/jira/browse/CASSANDRA-19677 >> >> For context, that Jira ticket (and PR) is adding a bunch of more fine >> grained size thresholds for column types using guardrails, expanding on what >> these Jiras added: >> https://issues.apache.org/jira/browse/CASSANDRA-17151 >> https://issues.apache.org/jira/browse/CASSANDRA-17150 >> >> Now, we have an alternative way to set sizes to scpecific columns using >> constraints (we have LENGHT constraint, which is technically different, but >> adding a SIZE constraint is on the roadmap and straight forward). >> >> Jordan raised a really valid concern that these new guardrails may be adding >> some noise to an already crowded space such as settings. On the other hand, >> these guardrails operate at a different level than constraints, as they are >> generic as opposed to column specific. >> >> We would like to hear what the community think in this case. Should these >> guardrails go in? Or do we drop them in favour of plain constraints? >> >> My two cents: My opinion is that these guardails still add value and help >> operators a more fine grained control to "protect" the database. >> >> Regards, >> Bernardo
