3

Before upgrading to Hibernate Search 5 from version 4.5, our system indexed all document ID's as numeric fields:

@Entity
public class Staff {
    @Id
    @NumericField
    protected Long id;
    // other fields
}

This allowed us to use numeric range queries. In Hibernate 5, all document IDs are indexed as strings, and the above annotation causes an exception. Without the annotation, all numeric range queries fail to properly search the ID fields.

Switching to TermRangeQuery instead of NumericRangeQuery will be tedious, and I'm hoping to avoid this.

Is there a way to continue treating IDs as numeric values?

Kevin
  • 4,070
  • 4
  • 45
  • 67
  • Is the exception raised during indexing or at query time? – Sanne Aug 11 '15 at 11:00
  • I have a test which confirms that I can't target the Id field with a NumericQuery, but I can index them as numerics just fine. Opened https://hibernate.atlassian.net/browse/HSEARCH-1960 , please let me know if this is your same problem? – Sanne Aug 11 '15 at 11:21

2 Answers2

5

You're correct, you have found a bug which I'm fixing now as HSEARCH-1960.

You can workaround the problem by defining an additional field for your Id property like this:

@Entity
public class Staff {
    @Id
    @Field(name="id_numeric")
    @NumericField(forField="id_numeric")
    protected Long id;
    // other fields
}

Then run your range queries on the field "id_numeric" rather than "id".

In future versions of Hibernate Search we will probably encode all Ids as DocValues, as that is much more efficient. That implies that the above workaround will be the best way to also be able to encode it as a NumericField.

Sanne
  • 6,027
  • 19
  • 34
0

I would not interfere with the way the id is indexed. In the future this might not even be possible anymore. Instead add an additional @Field. You can give the field a dedicated name as well via the annotation. Since the field is a Long it will be automatically numerically encoded.

Hardy
  • 18,659
  • 3
  • 49
  • 65