>> Projection
>
> What about .setCachedProjection or .setIndexedProjection to clearly
> signal
> it is not a "real" projection ?
But it *is* a real projection, just not from the database :-) The data
is the same though
The API is in FullTextQuery.setProjection()
Do we need the redundancy?
It's just that your other query results are "real" data from the db,
unless you
use setProjection() where it then starts returning purely indexed/cached
data instead.
Compare it to how we do 'cached' queries in "normal" hibernate api:
createFullTextQuery("blah blah").setProjection(...).list();
vs.
createQuery("blah blah").setCachable(true).list();
The latter is "obvious", the former is not IMO. It looks more like
Criteria API's
projection which again is assumed to return a consistent result instead of
a possible
cached/out-of-sync result.
>> 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.
>
> Shouldn't this result in an error ?! if the property is not actually
> "mapped"
> shouldn't it fail ?
I couldn't make my mind.
My choice comes from the fact that Lucene is a totally unstructured data
container.
For eg if you query
title:Hibernate summary:Rock
and if the documents don't have the summary field, it's silently ignored
by lucene
It's kinda cool if you want to retrieve let's say Dvd and Book, some
fields are shared and some are specific
Well can't you just verify if the field exists against the possible result
domain space (in
this case Dvd and Book) ? If the field does not exist at all it is
definitly an error.
>> Custom query to load objects
>> You can define the Criteria query that will be use to load the
>> matching objects of a lucene query.
>> This is especially useful when an object graph (rather than an
>> object) is expected: you can refine the fetchMode.
>>
>> result = s.createFullTextQuery( query ).setCriteriaQuery(
>> s.createCriteria( Book.class ).setFetchMode( "authors",
>> FetchMode.JOIN )
>> ).list();
>>
>> will load the matching books and the associated authors.
>
> What happens if the query and the criteria are totally unrelated ? And
> how are the link
> done between "query" and the Criteria ? you just add an in clause on
> the "id" property "blindly" ?
It can't be, I read the Criteria entity root to filter the unstructured
query
Yes I add an in clause (several actually, thanks Oracle) to the property
marked as @DocumentId
Ok - so it will just return an empty result if there is a mismatch.
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com