Yifan: how is the SIZE constraint from the LENGTH constraint? -> I think you are asking how are they different? They are similar, but not exactly the same. And it will depend on the actual type of the column they are added. For example, for a blob, both SIZE and LENGTH would be equivalent. But, for strings, they are difference. For the string “foo”, LENGTH would be 3, but size would be bigger than 3 (depending on the actual encoding used).
> On Feb 8, 2025, at 7:58 PM, Yifan Cai <yc25c...@gmail.com> wrote: > > It makes sense to me to have both guardrails (which is for operators) and > constraints (which is for app owners) to define size limits. Besides the > difference in the target audience groups, the scope where guardrail and > constraints are applicable also differs. > > However, it is unnecessary to reject constraints definition if it goes beyond > the relevant guardrail, as long as the write failure indicates whether the > size violates the guardrail or column constraint, which should be propagated > to clients for transparency. > > Btw, how is the SIZE constraint from the LENGTH constraint? > > - Yifan > > On Sat, Feb 8, 2025 at 6:25 PM Bernardo Botella <conta...@bernardobotella.com > <mailto:conta...@bernardobotella.com>> wrote: >> 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 >>> <mailto: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 >>
