[hibernate-dev] Hibernate Search, more API changes in SearchFactory

[Emmanuel Bernard]

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.