We already have many interfaces similar to these for Compaction Strategy, Indexing, Query Handler. I would hope that commiters are already following a policy along the lines of trunk -> anything goes, not trunk -> try not to change these interfaces. I would expect that to be the same policy for any new internal interfaces that are added. But given we already have many such interfaces, I see no reason to block adding more of them while change policies are discussed.
-Jeremiah > On Nov 9, 2021, at 10:44 AM, David Capwell <dcapw...@apple.com.INVALID> wrote: > > I still have one outstanding comment, but this is a comment for several of > the CEPs being worked on > >> And last comment, which I have also done in the other modularity thread… >> backwards compatibility and maintenance. It is not clear right now what java >> interfaces may not break and how we can maintain and extend such interfaces >> in the future. If the goal is to allow 3rd parties to plugin and offer new >> SSTable formats, are we as a project ok with having a minor release do a >> binary or source non-compatible change? If not how do we detect this? >> Until this problem is solved, I do not think we should add any such >> interfaces. > > I would love some clarity on this. Specifically, if we assume a patch > author/reviewers are not familiar with the impact of changes these > interfaces, what happens? Do we have tools to block this? Do we require 3rd > party authors to create massive shims to deal with every patch level version > out there? I would love more clarity on how we maintain these new pluggable > interfaces. > >> On Nov 9, 2021, at 4:45 AM, Branimir Lambov <blam...@apache.org> wrote: >> >> Does anyone have any further comments or questions on the proposal, or are >> we ready to move forward to a vote? >> >> Regards, >> Branimir >> >> On Tue, Nov 2, 2021 at 7:15 PM David Capwell <dcapw...@apple.com.invalid> >> wrote: >> >>>> I apologize I did not mention those things explicitly. All the places >>> where >>>> sstable files are accessed directly would have to be refactored. >>> >>> Works for me >>> >>>> Speaking about the implementation, one idea I was thinking about was that >>>> the factories for formats are registered using Java's native service >>>> loader. >>> >>> I am a fan of ServiceLoader as a means of plugging in. >>> >>>> I hope this explains a bit >>> >>> Yep; thanks! >>> >>>> On Nov 2, 2021, at 1:46 AM, Jacek Lewandowski < >>> lewandowski.ja...@gmail.com> wrote: >>>> >>>> David, >>>> >>>> I apologize I did not mention those things explicitly. All the places >>> where >>>> sstable files are accessed directly would have to be refactored. >>>> >>>> Regarding TableMetrics - currently it includes many metrics, some of them >>>> are unrelated to sstables at all, but there are metrics which are >>> specific >>>> to the current sstable format, like metrics related to index summaries or >>>> bloom filters. The created gauges query certain methods on sstable >>> reader - >>>> I think the only common metrics for sstables we can leave in TableMetrics >>>> are those for which there are query methods in generic sstable interface. >>>> Other metrics, specific to the certain sstable format should be >>> registered >>>> by the implementation itself. >>>> >>>> Speaking about the implementation, one idea I was thinking about was that >>>> the factories for formats are registered using Java's native service >>>> loader. This way we could get the list of all the factories on the >>>> classpath and call some method, like `registerMetrics` during system >>>> initialization. That could be also implemented in static initializer in >>> the >>>> factory but it would make it less obvious for the implementors where such >>>> initialization should be done. >>>> >>>> I hope this explains a bit >>>> >>>> Thanks, >>>> Jacek >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
