Re: [hibernate-dev] HSearch-133
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Attachments:
- attachment.html (text/html — 3.5 KB)