Hi,
basically the same mechanism is used in JDBC and DataSource:
https://docs.oracle.com/en/java/javase/25/docs/api/java.sql/java/sql/Wrapper.html
The above example in JDBC is well-known to me. E.g., the Postgresql
driver has speciifc methods to escape table names or other identifiers
that you need to construct dynamic sql queries in a safe way. On the
other hand, JDBC connections are almost always wrapped in connection
caches and the only thing you have are the abstract Connection
interface. Casting never works as it is almost always somehow wrapped.
Generally it is a good idea to do this when you want calsses be extended
and make it useable with wrappers like FilterIndexReader. But you have
to be careful when unwrapping stuff that may possible need handling in
the filter! If we define such a method it should by default NOT return
NULL and instead throw an exception. The default impl would return
itsself if the type fits. FilterReader would call it on the delegate by
default.
P.S.: We have the functionality already in Lucene, but it is missing the
"cast" functionality:
https://lucene.apache.org/core/10_5_0/core/org/apache/lucene/util/Unwrappable.html
Uwe
Am 03.07.2026 um 15:34 schrieb Alan Woodward:
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?
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:[email protected]
