Hi Dinesh, I am glad you asked.
1) A node just fails to start. It will print something like this while booting and the whole Cassandra process exits. Exception (org.apache.cassandra.cql3.constraints.InvalidConstraintDefinitionException) encountered during startup: Unrecognized constraint function: my_custom_constraint ERROR [main] 2025-08-15T16:22:26,675 CassandraDaemon.java:925 - Exception encountered during startup org.apache.cassandra.cql3.constraints.InvalidConstraintDefinitionException: Unrecognized constraint function: my_custom_constraint at org.apache.cassandra.cql3.constraints.ConstraintResolver.lambda$getConstraintFunction$1(ConstraintResolver.java:96) I consider this to be the most ideal case, because if we said that not-found constraints are just skipped, then a user would not necessarily notice this as they would think everything is OK, while it would be possible to insert invalid data. Failing the node to start until the jar is back on the class path is better than being able to insert invalid data, in my opinion. 2) Yeah, I have been following mostly these goals while providing this feature: a) if somebody runs Cassandra and they want to put constraints on their data, these constraints might be highly specific to the respective business to such a level that they are never going to make it public. It is just tailored very specifically to their needs. But at the same time, we make the life way more easier for them, because they do not need to patch Cassandra as such. If somebody has a policy to only run official releases, they can, while they can implement their constraints against well documented API so they get what they want and they do not need to maintain their own fork internally just to put more constraints in. b) if people realize it is easy to add constraints without a lot of hassle (I have even added buildable example of the implementation into examples/constraints for easy start), then they can for sure use that already and if they are tired of maintaining it themselves and if they think it will be beneficial for broader audience, they can just reach us, go through a ticket / formal review and make it happen. It really depends on what they want to do but I am trying to just lower the bar to the absolute minimum so this stuff is easily accessible and hopefully attracts more people. Regards On Fri, Aug 15, 2025 at 6:12 PM Dinesh Joshi <djo...@apache.org> wrote: > Stefan - I understand the motivation behind this feature. I totally am for > introducing it. I just have a couple questions - > > 1. What is Cassandra's behavior when custom constraints are used but are > missing on disk? I'm imagining a situation where someone failed to include > the jar in their deployment? > > 2. I would really like the community to bring their custom constraints > back to the project when possible. I imagine we could have a separate > constraints repo that they can contribute their constraints creating an > ecosystem for domain specific constraints that are reusable but we may not > want to ship in Cassandra by default. Users could optionally load these > into Cassandra if they'd like. > > None of these questions / suggestions are blockers to moving ahead with it. > > Thanks, > > Dinesh > > On Fri, Aug 15, 2025 at 8:53 AM Štefan Miklošovič <smikloso...@apache.org> > wrote: > >> I do not see any more activity on this thread so I will proceed. This >> does not seem to be controversial as there is already precedent in place >> and nobody vehemently objects. >> >> Regards >> >> On Mon, Aug 11, 2025 at 7:57 PM Mick <m...@apache.org> wrote: >> >>> >>> >>> > >>> > I have 0 issues with ServiceLoader, but I think the bigger question is >>> “what is a public api”. >>> >>> >>> >>> Let's also please be clear in separating what are our public SPIs and >>> our public APIs, as compatibility concerns are different for each. We >>> typically refer to both when mentioning API, but in the code something that >>> ends up being both can become unnecessarily painful. >>> >>
