[hibernate-dev] HSearch-133

Emmanuel Bernard emmanuel at hibernate.org
Tue Dec 18 03:44:06 EST 2007


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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20071218/80e92221/attachment.html 


More information about the hibernate-dev mailing list