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.
_______________________________________________
hibernate-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/hibernate-dev
