On Thu, 25 Aug 2011 12:09:50 +0200, Elmer van Chastelet
<evanchastelet(a)gmail.com> wrote:
Currently two basic ideas came to mind:
A - Have a SearchFactory.openIndexReader(Class<?> c,
FullTextFilterImplementor...): This is similar to how the IndexManager's
are gathered at query time, and is probably therefore easy to understand
I favor this version. I find the reason why you can and in your case even
have
to specify FullTextFilterImplementor instances not so obvious. It requires
some deeper understanding on how things hang together.
B - (to be further reviewed) Have something like
searchFactory.indexReaders().withShardingOptions( X, Y
).includeType(Class<?> z).openIndexReader(). This also adds the ability
to get an IndexReader for multiple classes.
I find 'withShardingOptions' too vague. How exactly does this relate to A
and solved its usecase? Also I find the API a little too fluent.
As is also mentioned in [1], there is currently no direct access to
the
index managers, so getting a FSDirectory is currently not possible in
4.0alpha1. I think HS should support this to offer the flexibility to
work on the Lucene indexes directly (for example, to build an auto
completion/spell check index from an existing index)
That's a question of moving 'getAllIndexesManager' from
SearchFactoryImplementor
higher up the hierarchy, right?
--Hardy