[hibernate-dev] Hibernate Search Projection

[Max Rydahl Andersen]

>>> 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 at hibernate.org
http://hibernate.org

JBoss a division of Red Hat
max.andersen at jboss.com