> We already have many interfaces similar to these for Compaction Strategy, > Indexing, Query Handler.
Today-I-Learned QueryHandler is not allowed to be touched in a minor… good to know… > not trunk -> try not to change these interfaces Outside of MBeans, I honestly do not know what interfaces fall into this group; and for MBeans we have tests which block breaking changes. The point I am making is that not everyone is aware of the rules, so having something in place to help enforce such rules should be thought about; if we want to add pluggable hooks with the intent that external parties can leverage such hooks, we should also add to the scope the maintenance of these interfaces (we should not assume “tribal knowledge” will work). I am not trying to ask for something large or something requiring a ton of work, I am just asking that this gets thought about during the project so it doesn’t get neglected. This could be as simple as an annotation like @ExposedTo3rdParties (Hadoop does this to show an interface is exposed and must be maintained), or it could be something like split directories (src/java = private, src/java-exposed = public); I am trying not to dictate an implementation, only trying to make sure we are setup to support the CEP after the work is done. > On Nov 9, 2021, at 9:52 AM, Jeremiah D Jordan <jeremiah.jor...@gmail.com> > wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
