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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
