[hibernate-dev] Hibernate Search 3.1

[Emmanuel Bernard]

On  Feb 26, 2008, at 06:41, Nick Vincent wrote:
>
>
> 2) Explaining results
>
> This uses the new DOCUMENT_ID projection introduced in 3.0.1  to
> explain query results (we need this so the customer can understand
> their search results in the backoffice interface).  I added an explain
> method to both implementations of FullTextQueryImpl which is only
> available by casting (e.g. no interface changes).  I think explain()
> is probably a fairly advanced function which it's acceptable to access
> by casting.

Wouldn't it make sense to expose the explain result (I imagine an  
Explanation object) as a projected field?

query.setProjection(..., EXPLANATION);


>
> 3) Counting results
>
> In the current implementation we only want to perform one Lucene query
> per search (all projected).  In order to get a resultcount and the
> results themselves it is currently necessary to invoke the Lucene
> query twice.

This is not true.

query.list(); //triggers a lucene query
query.getResultSize(); //does not since list() has already computed it

>
>
> 4) Caching filter BitSets
>
> In order to fix the problem with readers there's going to need to be a
> way of accessing the underlying readers of a CacheableMultiReader in
> order to store the appropriate references to cache by.  I think it's
> going to be better to either make the subReaders property public or to
> define an accessor for it.  I've done this locally so I can hack up a
> working caching strategy based on a weakreference to the first reader,
> which works for my case but not the general case.

An accessor seems the solution.

>
>
> Any feedback on these would be very useful.  I've made the changes
> locally, but would like some confirmation about direction before I
> start spraying patches around.
>
> Cheers,
>
> Nick
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev