[hibernate-dev] [Hibernate Search] Feedback on Document Field lazy loading

[Emmanuel Bernard]

On  Jun 15, 2008, at 04:24, Sanne Grinovero wrote:

> what is your goal? performance?

Performance, memory consumption, reduce the gap between entity loading  
and projection from a perf point of view (assuming projection loads  
the same amount of data).

>
>
> from the code I guess you don't intend to support something like
> setProjection( FullTextQuery.DOCUMENT,  "lastname" );

No, if you want a Document, you want it all most likely, otherwise a  
simple field projection will do it better and benefit from the fields.

>
>
> as you skip fieldnames processing when you hit DOCUMENT;
> I agree with you it would be a bit stupid, but someone could want
> to do that for some purpose.
>
> I generally don't like the return types as arrays very much, it  
> would be
> very cool to get anyway an entity containing only the projected data
> (a sort of extremely-lazy state) but I guess it would introduce a  
> lot of other
> problems. (overwrite and possibly change contained data when  
> (eventually) really loaded from DB?)

We had this goal in mind from day one (Vincent had actually). But this  
leads to a lot of problems including non unicity, the need to use  
bytecode enhancement etc. We can start a separate thread but we have  
more valuable features on the table before this one.

>
> What if you would permit uses to pass their own DocumentExtractor,  
> impl
> to return a wrapping object?
> This is what we do in the library system ( we just use Search to  
> build Documents, not for searching them),
> depending on the page view I know which fields I want to show and  
> have a simple bean to link to JSF,
> so I iterate on results and produce a list of beans with my own  
> pluggable logic, using a different one
> each time depending on the data need.

setProjection + a result transformer do that for you already feature  
wise

ftQuery.setProjection("firstname",  
"lastname").setResultTransformer(new  
AliasToBeanResultTransformer(PersonView.class) );

>
>
> org.hibernate.search.FullTextQuery hibQuery =  
> s.createFullTextQuery( query, Employee.class );
> DocumentExtractor dt = new EmployeeDocToFullnameExtractor();
> hibQuery.setProjection( dt );
>
> and nothing stops you to support some syntax as
> hibQuery.setProjection( FullTextQuery.THIS, FullTextQuery.SCORE,   
> dt );
> even if it is obviously redundant.
>
> IMHO you move the responsability of managing weird fieldbridges to  
> the users this way...

you mean in your solution or in mine?

>
>
> Sanne
>
> 2008/6/14 Emmanuel Bernard <emmanuel at hibernate.org>:
> I played around the idea of not loading unnecessary fields when  
> loading a Lucene document.
> It turns out this is not easily possible
> http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-213
>
> I would appreciate feedback in JIRA on this one.
>
>
> --
> Emmanuel Bernard
> emmanuel at hibernate.org
> http://in.relation.to
> http://blog.emmanuelbernard.com
> http://twitter.com/emmanuelbernard
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20080615/00f95a09/attachment.html