Sorting results from Hibernate Search issues.

chubbard · **Posted:** Thu Sep 20, 2007 1:09 am

I'm trying to return a search in a specific order. However, I'm not seeing any differences by switching ascending vs. decensing. Here is how I'm sorting:

Code:

            Criteria criteria = session
                    .createCriteria( MessageEntity.class )
                    .setFetchMode( "attachments", FetchMode.JOIN )
                    .addOrder( ascending ? Order.asc( orderBy ) : Order.desc( orderBy ) )
                    .setFirstResult( start ).setMaxResults( length );
            FullTextSession fullTextSession = Search.createFullTextSession( session );
            FullTextQuery fullTextQuery = fullTextSession.createFullTextQuery( parser.parse( searchString ), MessageEntity.class ).setCriteriaQuery( criteria );

This is producing the following hibernate query:

Code:

    select
        this_.ID as ID0_1_,
        this_.MESSAGE_BCC as MESSAGE2_0_1_,
        ... // took out a bunch of fields for brevity
        attachment2_.MESSAGE_ID as MESSAGE7_1_0_,
        attachment2_.CONTENT_TYPE as CONTENT6_1_0_ 
    from
        APP.MESSAGES this_ 
    left outer join
        APP.ATTACHMENTS attachment2_ 
            on this_.ID=attachment2_.MESSAGE_ID 
    where
        (
            this_.ID in (
                ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?
            )
        ) 
    order by
        this_.MESSAGE_DATE desc

I've read in the hibernate manual for search that they use the example of doing sorts with lucene, but the drawback to that is you only can search on fields that have been stored in the index. Tokenized fields are left around to sort on. However, since the hibernate query runs after the search it seems quite natural you could sort it in the DB instead of lucene which is what hibernate is doing. But, it doesn't work. It always returns it in the same order. You can see the Order by clause on the end of the statement.

I'm using Derby, Hibernate 3.3.0 GA, Hibernate Search 3.0.0 Beta 3. Any ideas what I'm doing wrong?

Charlie

emmanuel · **Posted:** Thu Sep 20, 2007 10:47 am

What you're trying to do does not work.
HSearch does not always run a query to read the object from the database, and it can potentially run several queries.
You must store the property you want to sort by in an untokenized way.
I don't remember when we added that, but definitely in CR1, you can define more than one @Field per property:

Code:

   @Fields( {
         @Field(index = Index.TOKENIZED, store = Store.NO),
         @Field(name = "summary_forSort", index = Index.UN_TOKENIZED, store = Store.YES)
         } )
   public String getSummary() {
      return summary;
   }



      hibQuery = s.createFullTextQuery( query, Book.class );
      sort = new Sort( new SortField( "summary_forSort", false ) ); //ASC
      hibQuery.setSort( sort );
      

chubbard · **Posted:** Thu Sep 20, 2007 11:37 am

What's the point of having two @Fields on the attribute? Wouldn't you just store it (Store.YES) and Index.TOKENIZED. Then the value would at least be in the index for Lucene Sorting.

I have a concern about this architecture choice. Forcing sorting only on Stored fields doubles storage requirements. I'd have to store it in the index tokenized, store it untokenized, AND in the DB.

I hear what you're saying, and if I want to do it then there is no choice. But, I could always just not use Hibernate Search and go straight Lucene to cut down on storage concerns.

Charlie

emmanuel · **Posted:** Thu Sep 20, 2007 4:13 pm

I am sorry I messed up some things, Field used for sorting must not be tokenized but they don't have to be stored. That's a Lucene requirement.
So if you need to search the field in a tokenized way and sort it, you need to have the property in 2 different fields.
I would not be too bothered by the index size though. an index by nature (especially tokenized fields) take less space that straight data) and disk is cheap.