On 18 mai 07, at 01:41, Max Rydahl Andersen wrote:
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?
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
But I will align with the majority here and better be strict first
and relax later.
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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
