-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 
Author Message
 Post subject: Search 3.2->3.3, no longer use double2sortableStr?
PostPosted: Tue Jan 11, 2011 12:21 am 
Beginner
Beginner

Joined: Wed Sep 30, 2009 5:29 am
Posts: 29
I've been using Search 3.2 for some time, employing double2sortableStr to handle Double values in my classes. I may have been doing it 'wrong' all along, and I'd appreciate some advice now I'm trying to move to Search 3.3.

e.g. one of my Entity classes has a attribute of type double:

Code:
   @Column(name="price")
   @Field(name="price", index=Index.UN_TOKENIZED, store=Store.YES)
   @FieldBridge(impl = SortableDoubleBridge.class)
   @Analyzer(impl=org.apache.lucene.analysis.SimpleAnalyzer.class)
   private double price;


SortableDoubleBridge is like this:
Code:
import org.apache.solr.util.NumberUtils;
public class SortableDoubleBridge implements TwoWayStringBridge, ParameterizedBridge {
   @Override
   public Object stringToObject(String stringValue) {
      return NumberUtils.SortableStr2double(stringValue);
   }

   @Override
    public String objectToString(Object object) {
       return NumberUtils.double2sortableStr((Double)object);
}

I built queries with code like this:

Code:
import org.apache.solr.util.NumberUtils;

         final RangeFilter priceFilter = new RangeFilter("price",
               NumberUtils.double2sortableStr(fromPrice),
               NumberUtils.double2sortableStr(toPrice),
               true, true);


I am aware RangeFilter is deprecated, but had trouble getting any other solution to work.

Using the libraries distributed with 3.3, I find solr.NumberUtils no longer exists, and perhaps the @NumericField annotation is 'the way forward' now. However, the docs say some padding is still required.

Should I still try to use solr.NumberUtils.double2sortableStr, or is there a better feature to use with Search 3.3? (e.g. @NumericField)

Perhaps I should create a custom Bridge and map doubles to my own padded String representation to be stored in the index? Surely such a bridge already exists?

For simple financial data (e.g. where we know the precision should be 2 or 4 decimal places), what is the recommended way to index and search such values with 3.3? Is there an example somewhere?

A little good advice would go a long way :)
Thanks
Nick


Top
 Profile  
 
 Post subject: Re: Search 3.2->3.3, no longer use double2sortableStr?
PostPosted: Tue Jan 11, 2011 12:18 pm 
Hibernate Team
Hibernate Team

Joined: Fri Oct 05, 2007 4:47 pm
Posts: 2536
Location: Third rock from the Sun
Hi Nick,
I'm sorry for the change. We strive to always have backwards compatibility in Hibernate Search, unfortunately Lucene and Solr change often, especially lately with the update from Lucene 2 to 3.
We managed to shield users from most changes, as our own API will always be backwards compatible (the org.hibernate.search package), but if you have to resort to org.solr or org.apache code, we can't do much about them removing classes and methods.

So the answer is yes, you should definitely move to use the @NumericField feature. It provides a significant performance improvement, and as you move to our API this kind of compatibility brackages changes shouldn't happen anymore.

From Lucene's javadoc:
Quote:
To sort according to a NumericField, use the normal numeric sort types, eg SortField.INT (note that SortField.AUTO will not work with these fields)

_________________
Sanne
http://in.relation.to/


Top
 Profile  
 
 Post subject: Re: Search 3.2->3.3, no longer use double2sortableStr?
PostPosted: Fri Jan 21, 2011 5:29 am 
Beginner
Beginner

Joined: Wed Sep 30, 2009 5:29 am
Posts: 29
The arrival of our first born child delayed my response to this somewhat :)

s.grinovero wrote:
I'm sorry for the change.

No worries.. change is good! :)

I dug up what claims to be some migration guides, but there's nothing there about @NumericField - http://community.jboss.org/wiki/Hiberna ... h_330Final

s.grinovero wrote:
So the answer is yes, you should definitely move to use the @NumericField feature. It provides a significant performance improvement, and as you move to our API this kind of compatibility brackages changes shouldn't happen anymore.

Great. I've slipped it into my project, removed my old bridge, and used a FilterDef approach to doing queries on ranges of values.. and it all seems to Just Work (tm). Fingers crossed!

s.grinovero wrote:
From Lucene's javadoc:
Quote:
To sort according to a NumericField, use the normal numeric sort types, eg SortField.INT (note that SortField.AUTO will not work with these fields)

I don't quite follow you there, but hopefully it will make sense in time.

Thanks for the advice :)
Nick


Top
 Profile  
 
 Post subject: Re: Search 3.2->3.3, no longer use double2sortableStr?
PostPosted: Fri Jan 21, 2011 6:01 am 
Hibernate Team
Hibernate Team

Joined: Fri Oct 05, 2007 4:47 pm
Posts: 2536
Location: Third rock from the Sun
Quote:
The arrival of our first born child delayed my response to this somewhat :)
Congratulations!
Quote:
I dug up what claims to be some migration guides, but there's nothing there about @NumericField - http://community.jboss.org/wiki/Hiberna ... h_330Final

@NumericField is a new feature, you don't need to use it so it won't be mentioned. The migration guide is really about potential issues where we track possible trouble for users of our API, in this case it's a Solr API change - we didn't know about that - still I agree it's useful to tell so I'm adding a reminder, thanks!

_________________
Sanne
http://in.relation.to/


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.