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
[EMAIL PROTECTED]
http://hibernate.org
JBoss a division of Red Hat
[EMAIL PROTECTED]
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
