This is correct, but Christian had a very interesting idea.
We could reuse the projection API to project the Lucene specific objects
fullTextQuery.setProjection("id", "title", "price",
FullTextQuery.DOCUMENT, FullTextQuery.SCORE).list();
Would return a list of
Object[] {
1, //the id
"Au bonheur des dames", //title
5.5, //price
org.apache.lucene.document.Document@123334, //"the raw Lucene doc"
.556, //the Lucene Score for the given document
}
The benefits being :
- a reductions of specific APIs (score, hits)
- an easy navigation (everything (objects and Lucene objects
accessible from the same array and API)
On Jun 18, 2007, at 4:15 AM, Hardy Ferentschik wrote:
Hi John,
> By the way could you please explain your 'projection' to me. I don't
> understand the concept.
The idea behind projections is to avoid full database round-trips
in uses cases where you are only interested in a subset of object
properties (instead of the full Hibernate managed object). Lucene
allows you to store the original values of the fields you are
indexing in the index itself. This functioanlity is exposed in
HSearch via the annotation @Field(store=Store.YES).
My favourite use case is a online shop. Normally such a site has
some sort of search functionality. Say that only the title, price
and category of an item is searchable and beeing displayed on the
search result page. If you store these properties in the lucene
index you can retrieve them at search time and just return these
'projected' values without accessing the database. When a user then
clicks on a single item you would normally retrieve the fully
managed Item object from the database (probably using the hibernate
id)
Projections will be returned as object arrays. Have a look at the
example in the HSearch documentation:
http://www.hibernate.org/hib_docs/search/reference/en/html_single/
#d0e1139
Cheers
Hardy