On Thu, 25 Aug 2011 12:09:50 +0200, Elmer van Chastelet <evanchaste...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
