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