9:19 p.m.
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
9:24 p.m.
Addendum:
"searchFactory.closeReader( indexReader );"
is much nicer to use as
"indexReader.close()":
the first one doesn't throw a java.io.IOException.
Cheers,
Sanne
9:01 a.m.
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.
10:17 a.m.
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
4652
days inactive
4653
days old
3 comments
2 participants
participants (2)
-
Emmanuel Bernard -
Sanne Grinovero