Noted for when we get to implement the SERIALIZED_SIZE constraint :-)
> El feb 8, 2025, a las 8:55 p. m., Yifan Cai <yc25c...@gmail.com> escribió:
>
> 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
> <mailto: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
>>> <mailto: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
>>>>
>>
