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 <[EMAIL PROTECTED]>: > 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 > [EMAIL PROTECTED] > http://in.relation.to > http://blog.emmanuelbernard.com > http://twitter.com/emmanuelbernard > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >
_______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
