Big -1 on forcing the user to supply the same similarity, We need to keep a similarity per entity in the SearchFactory so that the query can then retrieve it.

The reason I chose IndexReader (and Multireader) was because Searcher is a much weaker abstraction, so you cannot do all the things you can with IndexReader. The second point was that MultiReader is faster than MultiSearcher.

In case similarities are different across the query, FulltextQueryImpl can extract a reader per similarity (i.e. calling ReaderProvider.openReader with all the DirectoryProviders sharing the same similarity) and wrap them around a MultiSearcher.
Let's do this work in FulltextQueryImpl for now.

Note that if a given DirectoryProvider stores entities having different similarities, we can no longer share it: that sucks!

On  Dec 16, 2007, at 23:02, John Griffin wrote:

Emmanuel,

 

I have the index creation working. About searching though, the user will have to supply the similarity class. There is no way of knowing what similarity was use to build an index and Similarities must be kept the same between indexing and searching or results are undefined. The query had to be told. Do you want to have a similarity setter in FullTextQueryImpl or an overloaded constructor.

 

When we created the index, each entity could have its own similarity. If this is the case the similarity will have to be identified by entity. To do this we will have to build a MultiSearcher instead of a MultiReader. The Similarity can only be set on Searchables. I don’t think this is a big issue, it’s not that big or difficult of a change to make. Thoughts?

 

John G.

_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev