In Chapter 1, Your First Application, we saw that member variables on a Hibernate-managed class are made searchable with the @Field annotation. Hibernate Search will put information about annotated fields into one or more Lucene indexes, using some sensible defaults.
However, you can customize indexing behavior in numerous ways, some of which are optional elements in the
@Field annotation itself. Most of these elements will be explored further throughout this book, but we will briefly introduce them here in one centralized list:
analyze: This tells Lucene whether to store the field's data as is, or put it through analysis, parsing, and processing it in various ways. It can be set toAnalyze.YES(the default) orAnalyze.NO. We will see this again in Chapter 3, Performing Queries.index: This controls whether or not the field should be indexed by Lucene. It can be set toIndex.YES(the default) orIndex.NO. It may sound nonsensical to use the@Fieldannotation and then not index the field, but this will make more sense after seeing projection-based searches in Chapter 5, Advanced Querying.indexNullAs: This declares how to handle null field values. By default, null values will simply be ignored and excluded from Lucene indexes. However, with this element fully covered in Chapter 4, Advanced Mapping, you can force null fields to be indexed with some default value instead.name: This is a custom name, describing this field in the Lucene indexes. By default, Hibernate Search will use the name of the annotated member variable.norms: This determines whether or not to store index-time information used for boosting, or adjusting the default relevance of search results. It can be set toNorms.YES(the default) orNorms.NO. Index-time boosting will appear in Chapter 4, Advanced Mapping.store: Normally, fields are indexed in a manner optimized for searching, but this might not make it possible to retrieve the data in its original form. This option causes the raw data to be stored in such a way that you can later retrieve it directly from Lucene, rather than the database. It can be set toStore.NO(the default),Store.YES, orStore.COMPRESS. We will use this with projection-based searches in Chapter 5, Advanced Querying.
Sometimes, you need to use one set of options to do certain things with a field, and other set of options to do other things. We will see this later in Chapter 3, Performing Queries when we make a field both searchable and sortable.
For the time being, suffice it to say that you can have as many custom mappings as you wish for the same field. Just include multiple @Field annotations, wrapped within the plural @Fields:
...
@Column
@Fields({
@Field,
@Field(name="sorting_name", analyze=Analyze.NO)
})
private String name;
...Don't worry too much about this example right now. Just note that when you create more than one mapping for the same field, you need to give them distinct names with the name element, so that you can later reference the correct mapping.
In Chapter 1, Your First Application, our entity mapping examples dealt exclusively with string properties. It is likewise perfectly fine to use the same @Field annotation with other basic data types as well.
However, fields mapped this way are indexed by Lucene in string format. That is very inefficient for techniques that we will explore later, such as sorting and querying over a range.
To improve the performance of such operations, Hibernate Search offers a specialized data structure for indexing numeric fields. This option is available when mapping fields of type Integer, Long, Float, and Double (or their primitive counterparts).
To use this optimized data structure for a numeric field, you simply add the @NumericField annotation in addition to the normal @Field. As an example, let's give the App entity in our VAPORware Marketplace application a field for price:
...
@Column
@Field
@NumericField
private float price;
...If you are applying this annotation to a property that has been mapped multiple times with @Fields, you must specify which of those mappings should use the specialized data structure. This is done by giving the @NumericField annotation an optional
forField element, set to the same name as the desired @Field.