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