NOTE in Java

Maker Data Matrix ECC200 in Java NOTE

The authors do not imply that the object model is superior to the index model. Both have their respective strengths. In particular, the unstructured nature of the index model provides a great deal of flexibility that s absolutely essential for a multipurpose search engine. As a matter of fact, Hibernate Search heavily depends on the unstructured flexibility provided by Lucene.

Because the two models have conceptual differences in the way they represent data (see figure 3.1), some conversion is necessary when representing the same data in the two models. Let s explore these differences and see how Hibernate Search reconciles them. We ll deal with three main issues: converting the overall structure, converting types, and defining the fine-grained indexing strategy.

The coarse-grained element we want to index is the entity. In the object world, it is represented as a class instance. Hibernate Search represents each class instance as a Lucene Document instance, a Document being the atomic piece of information retrievable by a Lucene search. Queries will then retrieve entities corresponding to the Document instances. Java classes can be subclassed and, thanks to that, inherit the data structure from their superclass. Unfortunately, Lucene Documents have no notion of subclassing. Even worse, it s impossible to execute queries on correlated Documents because such a notion doesn t exist in Lucene. This isn t a problem in practice, and Hibernate Search maps each subclass instance in its own Document. The Document for a given subclass will contain the data from the subclass attributes as well as the data from all the mapped superclass s attributes. Think of this mapping strategy as a denormalized model. For people familiar with Hibernate s inheritance-mapping strategies, you can see this as equivalent to the table-per-concrete-class mapping strategy.

You now know how Hibernate Search maps the coarse-grained structure of domain models. Let s discuss how each entity attribute is mapped into the Lucene world. Each attribute or property considered to be indexed is mapped as a Lucene field whose default name will be the property name. While the Lucene field name can be overridden, as we will show later, the authors recommend you not do it because the one-toone mapping between a property name and a field name will make it easier both to write and, more importantly, read Lucene queries. One-to-one mappings can be made between a property and a field, but how does Hibernate Search convert the Java type into a string the only type searchable by Lucene

As previously described, the only type Lucene can speak is string. Unfortunately (or fortunately, depending on how you see things), in Java, attributes can be of many different types. A URL is treated differently from a date or a number. Numbers are represented by different types depending on what they represent and their range of expectation, from short for small integer numbers up to BigDecimal for arbitraryprecision decimal numbers. Hibernate Search needs to convert each possible type into a string representation. For that, Hibernate Search has the notion of field bridge: A field bridge is a bridge between the Java type and its representation in the Lucene Field, or, to make it simpler, a bridge between a Java object and its string representation. Hibernate Search comes with a set of built-in field bridges for most of the Java standard types. But it isn t limited to them. In the next chapter we ll explore how you can further extend Hibernate Search support by writing a custom field bridge. Once a type is converted into a string, the value needs to be indexed.

Hibernate Search, by default, doesn t represent null attributes in the index. Lucene doesn t have the notion of null fields; the field is simply not there. Hibernate Search could offer the ability to use a special string as a null marker to still be able to search by null values. But before you jump at the Hibernate Search team s throats, you need to understand why they have not offered this feature so far. Null is not a value per se. Null means that the data is not known (or doesn t make sense). Therefore, searching by null as if it were a value is somewhat odd. The authors are well aware that this is a raging debate, especially among the relational model experts (see http://en.wikipedia.org/ wiki/Null_%28SQL%29). Whenever you feel the need to searching by null, ask yourself if storing a special marker value in the database would make more sense. If you store a special marker value in the database, a lot of the null inconsistencies vanish. It also has the side effect of being queriable in Lucene and Hibernate Search.