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

[Sanne Grinovero]

what is your goal? performance?

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

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?)
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.

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...

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/a23aa06f/attachment.html