Re: [hibernate-dev] Hibernate Search, more API changes in SearchFactory
2011/7/25 Emmanuel Bernard <emmanuel(a)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:
searchFactory.getIndexMappingForEntity(Class<T>
entityType).getIndexManagers() [ shardIndex ] .openReader();
or alternatively:
searchFactory.getAllIndexesManager().getIndexManager(String
targetIndexName).openReader();
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.
Cheers,
Sanne