> > trunk -> anything goes, not trunk -> try not to change these interfaces
Have we ever clarified what "these interfaces" are? Was just talking to David and I realized I didn't even JavaDoc CommitLogReadHandler as _being designed_ for external usage. /sigh I think it'd be valuable for us to go through the codebase and annotate interfaces as intended to be exposed to 3rd parties; this has bothered me for years. Especially as we come up on a large number of new cleanups, refactorings, and potentially genericizing some subsystems into API's (CEP-18 descendents). On Tue, Nov 9, 2021 at 2:01 PM David Capwell <dcapw...@apple.com.invalid> wrote: > > 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 > >
