<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 15, 2008, at 04:24, Sanne Grinovero wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">what is your goal? performance?</blockquote><div><br></div><div>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).</div><br><blockquote type="cite"><br><br>from the code I guess you don't intend to support something like<br>setProjection( FullTextQuery.DOCUMENT, "lastname" );</blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><br><br>as you skip fieldnames processing when you hit DOCUMENT;<br> I agree with you it would be a bit stupid, but someone could want<br>to do that for some purpose.<br><br>I generally don't like the return types as arrays very much, it would be<br>very cool to get anyway an entity containing only the projected data<br> (a sort of extremely-lazy state) but I guess it would introduce a lot of other<br>problems. (overwrite and possibly change contained data when (eventually) really loaded from DB?)</blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><br>What if you would permit uses to pass their own DocumentExtractor, impl<br> to return a wrapping object?<br>This is what we do in the library system ( we just use Search to build Documents, not for searching them),<br>depending on the page view I know which fields I want to show and have a simple bean to link to JSF,<br> so I iterate on results and produce a list of beans with my own pluggable logic, using a different one<br>each time depending on the data need.</blockquote><div><br></div><div>setProjection + a result transformer do that for you already feature wise</div><div><br></div><div>ftQuery.setProjection("firstname", "lastname").setResultTransformer(new <span class="Apple-style-span" style="font-family: Monaco; font-size: 11px; ">AliasToBeanResultTransformer(PersonView.class) );</span></div><br><blockquote type="cite"><br><br>org.hibernate.search.FullTextQuery hibQuery = s.createFullTextQuery( query, Employee.class );<br> DocumentExtractor dt = new EmployeeDocToFullnameExtractor();<br>hibQuery.setProjection( dt );<br><br>and nothing stops you to support some syntax as<br>hibQuery.setProjection( FullTextQuery.THIS, FullTextQuery.SCORE, dt );<br> even if it is obviously redundant.<br><br>IMHO you move the responsability of managing weird fieldbridges to the users this way...</blockquote><div><br></div><div>you mean in your solution or in mine? </div><br><blockquote type="cite"><br><br>Sanne<br><br><div class="gmail_quote">2008/6/14 Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>>:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I played around the idea of not loading unnecessary fields when loading a Lucene document.<br> It turns out this is not easily possible<br> <a href="http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-213" target="_blank">http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-213</a><br> <br> I would appreciate feedback in JIRA on this one.<br> <br> <br> --<br> Emmanuel Bernard<br> <a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a><br> <a href="http://in.relation.to" target="_blank">http://in.relation.to</a><br> <a href="http://blog.emmanuelbernard.com" target="_blank">http://blog.emmanuelbernard.com</a><br> <a href="http://twitter.com/emmanuelbernard" target="_blank">http://twitter.com/emmanuelbernard</a><br> <br> _______________________________________________<br> hibernate-dev mailing list<br> <a href="mailto:hibernate-dev@lists.jboss.org" target="_blank">hibernate-dev@lists.jboss.org</a><br> <a href="https://lists.jboss.org/mailman/listinfo/hibernate-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/hibernate-dev</a><br> </blockquote></div><br></blockquote></div><br></body></html>