<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">I have been adding new features on Hibernate Search recently (SVN)<DIV><BR class="khtml-block-placeholder"></DIV><DIV><B>Projection</B></DIV><DIV>The ability to project some fields the index only avoiding the database roundtrip.</DIV><DIV>fullTextQuery.setProjection("id", "summary", "author.name").list();</DIV><DIV>will return a List<Object[]> like the regular HQL projection</DIV><DIV>the fieldbridge has to be two way (all built-in are) and the projected fields have to be Store.YES or Store.COMPRESS</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>It's useful when you want to display a small subset of the data, don't want managed objects, are OK to have a bigger index and if the performance of the non projection strategy doesn't meet your requirements (arguably uncommon);</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>A few questions:</DIV><DIV>Currently fields Store.NO or where the fieldbridge is one way are ignored and return null.</DIV><DIV>The idea behind that is to be able to project across multiple entities / index. Not sure if it's a useful feature.</DIV><DIV>What do you think of the API? I thought about reusing the Criteria Projection API but it's too tight to SQL</DIV><DIV>If people could give it a try...</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><B>Object load by query rather than batch-size</B></DIV><DIV>When querying a given entity type ( eg ftSession.createFullTextQuery(luceneQuery, Book.class) ). HSearch now use a query with an in clause, reducing the number of database roundtrip especially if you don't set up @BatchSize on the entity</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><B>Custom query to load objects</B></DIV><DIV>You can define the Criteria query that will be use to load the matching objects of a lucene query.</DIV><DIV>This is especially useful when an object graph (rather than an object) is expected: you can refine the fetchMode.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>result = s.createFullTextQuery( query ).setCriteriaQuery(</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>s.createCriteria( Book.class ).setFetchMode( "authors", FetchMode.JOIN ) </DIV><DIV> ).list();</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>will load the matching books and the associated authors.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><B>Sorting (thanks to Hardy)</B></DIV><DIV>fullTextQuery.setSort(luceneSort).list();</DIV><DIV>Remember that a sorted field must not be tokenized</DIV><DIV>I will add the ability to index a property multiple times to cope with that.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><B>Expose resultSize()</B></DIV><DIV>ie the total number of result regardless of the pagination</DIV><DIV>fullTextQuery.setMaxResult(20)resultSize() == 3000</DIV><DIV>A better name is more than welcome.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><B>@IndexedEmbedded for collections</B></DIV><DIV>What was available for regular objects is now possible for collections</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I am fairly happy with the feature set for beta2, I will probably close a couple of issues and release beta2 (round end of next week, no guaranty though).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Feedback on those features are welcome esp projection, custom query and their APIs</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Emmanuel</DIV></BODY></HTML>