> Projection
> The ability to project some fields the index only avoiding the
> database roundtrip.
> fullTextQuery.setProjection("id", "summary",
"author.name").list();
> will return a List<Object[]> like the regular HQL projection
> the fieldbridge has to be two way (all built-in are) and the
> projected fields have to be Store.YES or Store.COMPRESS
Looks good to me. It is a shame so that you have to specify the
index field names explicitly as strings.
I wonder if there could be another way? On the one hand you are
able to index a field just via annoation,
not caring what the lucene field name will be, on the other hand
you have to use the field names in the projection.
Unfortunately, I haven't used projections before so I have to
understand the code first.
My main question right now - what type of objects are returned from
the query? Partly populated objects of the
managed classes or some other sort of objects?
Nevertheless, I will try it right away. I was basically looking for
a solution which would not go all the way to the
database.
What is retrieved is an Object[], it's a true projection, like a HQL
one, I will add the resultTransformer feature later on though, so the
Object[] can be converted.
You assume that someone will want to retrieve all the stored fields
and that HSearch can guess the list of fields. But it may very well
be a subset of the stored fields depending on the query, hence the
actual list of fields. Then if I return an Object[], with all fields,
the question of the ordering pops up.
My idea was to keep it consistent with what users do today in Hibernate.
> A few questions:
> Currently fields Store.NO or where the fieldbridge is one way are
> ignored and return null.
> The idea behind that is to be able to project across multiple
> entities / index. Not sure if it's a useful feature.
I guess I would expect an error if I include a field to be
projected, but it is not stored in the index.
OK I will change that
> Expose resultSize()
> ie the total number of result regardless of the pagination
> fullTextQuery.setMaxResult(20)resultSize() == 3000
> A better name is more than welcome.
I would also opt for getResultSize()
OK