We could also make it so that if we detect that a constraint is not resolvable, we would just skip it. However I am not sure how safe that is and what is worse - to fail to start a node when constraints are not present, or to continue to act as if nothing happened while somebody could put there invalid data. I think that in that case failing is just better.
On Mon, Aug 11, 2025 at 7:26 PM Štefan Miklošovič <smikloso...@apache.org> wrote: > I do not think it is there just for testing. The original patch includes > this commit message: > > Fix sstable formats configuration > > - refactored sstable format configuration > - sstable formats are discovered via ServiceLoader > ... > > So the fact it is explicitly stated like this does not seem to be related > just to testing only but it is a feature which is officially advertised. > > Here Jacek asks if we can use ServiceLoader (1) and here you answer to him > (2) that you 100% support this. > > I have not dug deep but it seems that it is not related to tests. Here (3) > Caleb says in 1) that it mimics what Lucene does. > > To your points about "what happens when it is not there". Yes, this is a > problem. But I do not think that this is something tremendously serious. > This is for users who know what they do and why. They would need to > specifically implement an interface and put it on CP and it would be their > responsibility to ensure it is everywhere. If they ever want to get rid of > that implementation, I think they would need to: > > 1) remove these constraints in the first place so they are not present in > any schema > 2) is not there something like TCM checkpoint or similar which would make > it all consolidated? What I mean by that is that it would not be replayed > from the very first epoch to the last one as it would go through epochs the > constraints are not in anymore (hence it would fail, similar to (4)) > > There is a similar problem to this in 4) (same for custom indexes etc) and > I do not think that we will solve this here. > > (1) > https://issues.apache.org/jira/browse/CASSANDRA-18441?focusedCommentId=17711283&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17711283 > (2) > https://issues.apache.org/jira/browse/CASSANDRA-18441?focusedCommentId=17711500&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17711500 > (3) > https://issues.apache.org/jira/browse/CASSANDRA-18441?focusedCommentId=17711539&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17711539 > > (4) https://issues.apache.org/jira/browse/CASSANDRA-20287 > > > On Mon, Aug 11, 2025 at 6:55 PM David Capwell <dcapw...@apple.com> wrote: > >> I have 0 issues with ServiceLoader, but I think the bigger question is >> “what is a public api”. In #1 I see the first comment is >> >> > The `CustomConstraintsProvider` class will create custom constraints. >> >> >> This implies to mean that this is a new public API that must be >> maintained, and the current process for these is to reach out to dev@. >> We don’t have any process to even know what is public API nor do we do >> anything to make sure we don’t break compatibility with java APIs. >> >> >> In the example you shown with SSTables, the format isn’t public API (at >> least thats my memory), this was kinda mostly done to enable testing. AKA >> if someone tries to use this and one of our patch fix versions makes a >> breaking change, thats on you for using a private API. >> >> > For constraints, I think it would be very welcome if people are allowed >> to code their own constraints and just put it on CP and it would be picked >> up automatically. >> >> If they are not stored in TCM and side loaded into each node, what >> happens when some of the nodes do not have them loaded? This had been a >> big pain point with the memtable patch (issue is partially fixed, we no >> longer crash, but we no longer respect user configs either). >> >> >> > On Aug 11, 2025, at 8:31 AM, Štefan Miklošovič <smikloso...@apache.org> >> wrote: >> > >> > I want to ask what people think about ServiceLoader's (Java SPI) in the >> context of Cassandra. >> > >> > There is already a precedent with >> > >> > ServiceLoader<SSTableFormat.Factory> loader = >> ServiceLoader.load(SSTableFormat.Factory.class, >> DatabaseDescriptor.class.getClassLoader()); >> > >> > in DatabaseDescriptor.applySSTableFormats >> > >> > I am asking because I would like to do (1, 2) and I find SPI to be the >> most suitable for it. Just drop a JAR among Cassandra jars and be done with >> it. >> > >> > This means that there is no change in the configuration of >> cassandra.yaml and similar. On the other hand, we kind of lose the >> visibility of what we are actually running. What I mean by that is that >> when it is configured in cassandra.yaml and done as "ParameterizedClass", >> it is pretty explicit what configuration we use for what. On the other >> hand, by placing a JAR to Cassandra class path, while it is super simple to >> do, the only visible way to tell a user if there is some custom stuff >> loaded is to log it as Cassandra starts. >> > >> > What do you think about the SPI approach in general? There might also >> be other advantages as providing more implementations and ordering them by >> priority etc. >> > >> > Is SPI's way of registering / loading custom implementations just fine >> and can be considered as something developers can choose to do if they >> think it fits the use-case enough? >> > >> > For constraints, I think it would be very welcome if people are allowed >> to code their own constraints and just put it on CP and it would be picked >> up automatically. It would speed up the development, they would not need to >> wait for us to merge them and release them and they could have proprietary >> / in-house constraints just for their use case while they do not need to >> patch Cassandra itself. Hence they can still use the official release but >> they could extend it as they want. >> > >> > Regards >> > >> > (1) >> https://github.com/apache/cassandra/pull/4297/files#diff-d6e8754d8326be6063d9d59265e882416d74007e47f07f809267b07f9860e26d >> > (2) https://issues.apache.org/jira/browse/CASSANDRA-20824 >> >>
