On 24 juil. 2011, at 21:19, Sanne Grinovero wrote:
Hello,
I'm thinking to hide the ReaderProvider API from the public interface;
it will still be available at SPI level, but I would prefer to keep
the option open to remove the ReaderProvider altogether in a near
future (replacing it by something similar).
SPI for which purpose? Which integration framework would need it?
This API is currently used when the end user needs "low level" access
to the index by getting control of an IndexReader, but currently he
needs to pass in the DirectoryProviders (gone already),
so I'd transform the API usage from current:
DocumentBuilder builderForX = searchFactory.getDocumentBuilder();
DirectoryProvider[] targetDps = // find out which DPs you want from
each documentBuilder (??? -- quite some questions on this usually)
IndexReader indexreader =
searchFactory.getReaderProvider().openReader( targetDps );
try {
//play with reader
}
finally {
searchFactory.getReaderProvider().closeReader( indexReader );
}
into this:
IndexReader indexReader = getSearchFactory().openIndexReader(
LargeDocument.class, OtherType,class );
try {
//play with reader
}
finally {
searchFactory.closeReader( indexReader );
}
My slight concern is that you no longer an select one shard or a subset of and open an
indexReader on top of it. Is that a valid use case?
Should these method be hosted on SearchFactory or on some other object accessible from the
SF?
Or for the closing stage we could go so far to require only
indexReader.close();
We could have done that for the previous API I think but I introduced the close method to
be more symmetric and make it easier to track bugs.
PS don't forget to mention all that in the migration guide.