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

Sanne Grinovero sanne at hibernate.org
Mon Jul 25 04:17:23 EDT 2011

2011/7/25 Emmanuel Bernard <emmanuel at hibernate.org>:
> 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?

Not that I know of, we could demote it to the implementor level.

>> 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?

Not sure if that's a common use case, but is certainly valid. There
are alternative strategies which involves more hops; method names are
not final as I expect them to be set when we'll review my pull
request, currently it would look like as:

entityType).getIndexManagers() [ shardIndex ] .openReader();

or alternatively:


But both these methods won't return a MultiReader but a vanilla
read-only IndexReader, targeting the single index.

BTW, likely the [ shardIndex ] will be replaced by a map instead of an
array, so get( String shardName ) to better fit with dynamic sharding.


More information about the hibernate-dev mailing list