> 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
