Thanks for the example. "SIZE" is in fact "SERIALIZED_SIZE".
The term size and length are mostly interchangeable. Some modifiers on size will be required in order to distinguish. - Yifan On Sat, Feb 8, 2025 at 8:50 PM Bernardo Botella < conta...@bernardobotella.com> wrote: > 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> 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> 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> 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 >> >> >> >
