Yes, that is correct. This particular behavior will need CEP-24 in order to
work reliably. But, if my understanding is correct, that statement holds true
for the entirety of Guardrails, and not only for this particular feature.
> On Jun 3, 2024, at 3:54 PM, Miklosovic, Stefan
> wrote:
>
> Tha
That would work reliably in case there is no way how to misconfigure guardrails
in the cluster. What if you set a guardrail on one node but you don’t set it
(or set it differently) on the other? If it is configured differently and you
want to check the guardrails if constraints do not violate th
Basically, I am trying to protect the limits set by the operator against
misconfigured schemas from the customers.
I see the guardrails as a safety limit added by the operator, setting the
limits within the customers owning the actual schema (and their constraints)
can operate. With that visio
You wrote in the CEP:
As we mentioned in the motivation section, we currently have some guardrails
for columns size in place which can be extended for other data types.
Those guardrails will take preference over the defined constraints in the
schema, and a SCHEMA ALTER adding constraints that br
