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(a)hibernate.org&gt;:

Sorry, that was bogus. Not sure what I was thinking. I should have looked at the code first. Of course we need the bridges in the projection case and for loading managed objects we just need the id. --Hardy On Sun, 15 Jun 2008 12:01:10 +0200, Hardy Ferentschik <hibernate(a)ferentschik.de&gt; wrote:

On Sun, 15 Jun 2008 18:22:22 +0200, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: True, but that is really an exceptional case. In most cases the added field names will be constant, otherwise it is damn hard to write a query. getFieldNames(String name) could return null in case the field names are dynamic. The API is not 100% intuative this way, but I think I still would prefer a explicit list of field names over a enum type like EXACT, IN_NAMESPACE or NON_SAFE. --Hardy

On Jun 15, 2008, at 04:24, Sanne Grinovero wrote: 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). 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. 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. setProjection + a result transformer do that for you already feature wise ftQuery.setProjection("firstname", "lastname").setResultTransformer(new AliasToBeanResultTransformer(PersonView.class) ); you mean in your solution or in mine?