On Thu, Jun 6, 2024 at 1:50 PM Bernardo Botella <
conta...@bernardobotella.com> wrote:
> I will update the CEP being specific with the two specific Constraint
> types I will be adding, which are size and value (the ones shown in the
> example).
>
Could you identify constraints for the most common
On Thu, Jun 6, 2024 at 1:03 PM Štefan Miklošovič <
stefan.mikloso...@gmail.com> wrote:
> It is interesting to see this feedback. When I look at CEP-24 where I am
> obsessing about a user being able to misconfigure the password validation
> strength so if a user hits a "weak" node then she would be
Similarly in the "don't use them in the main project but am ok with tests"
camp
On Thu, Jun 6, 2024 at 4:46 AM Štefan Miklošovič <
stefan.mikloso...@gmail.com> wrote:
> I have created
>
> https://issues.apache.org/jira/browse/CASSANDRA-19673
>
> to gather all your ideas about what to remove. If y
Thanks for the clarification Jon.
I will update the CEP being specific with the two specific Constraint types I
will be adding, which are size and value (the ones shown in the example).
And, just to clarify, the mention to extensibility just aims to state that the
feature should be built in a
I think figuring out a roadmap and strategy ahead of time is of high value,
but we don't necessarily have to implement everything all at once. As long
as we identify the problematic cases, and provide guidance (for example:
disable guardrails or constraints when replaying traffic with FQL), then I
It is interesting to see this feedback. When I look at CEP-24 where I am
obsessing about a user being able to misconfigure the password validation
strength so if a user hits a "weak" node then she would be able to bypass
it, and I see what is our approach here, then I am not sure what I was
waiting
To me, the difference between system-level guardrails and table-level
constraints is the difference between operational concerns (guardrails) and
business concerns (table-level constraints). The two things are only related to
one another because they both may limit the value of a field in some w
OK so let's modify that example like this:
T0 - a node is started with no guardrails set
T1 - guardrail is set via JMX to not allow anything bigger than size of 10
(whatever size means)
T2 - a user creates a table with a constraint that anything bigger than
size of 8 is forbidden
T3 - a user inser
Hi Stefan,
Thanks for putting the FQL example! However, it seems to be incorrect. FQL
only records the _successful_ queries. The query at T4 fails, and it will
not be included in FQL log.
I do agree that changing guardrails on the fly can cause confusion when FQL
is enabled on the node. Operator s
Another problem with this constraints feature is that if it does not solely
rely on constraints in CQL, then it would be non-deterministic if we want
to replay all mutations from a fql log.
Let's take this into consideration (T = time)
T0 - a node is started with no guardrails set
T1 - guardrail
I have created
https://issues.apache.org/jira/browse/CASSANDRA-19673
to gather all your ideas about what to remove. If you stumble upon some
code which is susceptible to rewriting, just put it there.
On Wed, Jun 5, 2024 at 6:35 PM wrote:
> I would like to vote for banning streams in all non-te
I agree with Jon that a detailed description of all constraints to be
introduced is necessary. Only to say that it will be extensible so we can
add other constraints later is not enough. What other constraints?
On Thu, Jun 6, 2024 at 6:24 AM Jon Haddad wrote:
> I think there's some promising ide
12 matches
Mail list logo
