Hi Adrien, Thanks for your reply.
A further thought... the use-case here is really for custom subclasses to “add additional” diagnostics, rather than “replace”. How about we expose just that functionality in SegmentInfo, e.g. through a new method similar to: /** * Adds the given {@code diagnostics} to this segment's diagnostics. * @param diagnostics the diagnostics to add */ public void addDiagnostics(Map<String, String> diagnostics) { ... } This would satisfy the ES use-case, while disallowing a full replace. If we think that there are other use-cases that require "replace" (or it is preferred to defer API discussion for a later time), then I'm happy to proceed with simply making the existing `setDiagnostics` method public. -Chris. > On 24 Sep 2021, at 17:30, Adrien Grand <jpou...@gmail.com> wrote: > > I'd +1 a change that makes setDiagnostics public. Longer term I wonder if we > should have a more locked down API that _only_ allows setting diagnostics. > There are lots of things in SegmentCommitInfo that merges should never > override like the segment ID, and I can't think of anything else than > diagnostics that a merge policy should ever need to set. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org