Hi all,
I’ve been catching up with the talks from Buzzwords this year and watching this
(excellent!) talk from Shailesh (https://www.youtube.com/watch?v=ziRcxCJPU6s)
on star-tree indexes in OpenSearch made me think again about the way we make
index structures available on LeafReader. The star-tree index is a novel
structure that I don’t think it would make sense to add to the base API, but on
the other hand there isn’t currently an obvious extension point that makes it
easy to use without doing some hairy casting of LeafReader types. We have a
similar issue in elasticsearch with bloom filters - useful in a restricted set
of circumstances, probably not helpful to have cluttering up the API, so we end
up implementing it in a custom Codec and then casting at runtime to see if
things are available (with the usual problems about FilterLeafReader wrapping
that comes with relying on casts). This also applies to Codec-specific
extensions to things like DocValueSkippers.
What do people think about adding a new method to the LeafReader API that looks
like this:
/** Return a data structure accessed through type T if available */
T getDataStructure(Class<T> structureType) {
return null;
}
Expert users implementing their own Codecs can use this to return specialised
data structures without polluting the top-level API or having to use fragile
casts.
Any opinions?
