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).
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 );
}
Or for the closing stage we could go so far to require only
indexReader.close();
Keeping the current API is not an option unless we throw away all what
I've already done for (HSEARCH-750, HSEARCH-761).
This is already in my current experimental branch, without the
"indexReader.close()" option as I'm not liking the asymmetry of the
operation (closing it differently than how I opened it).
WDYT?
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
