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 > >
