ORM Search Validator Reactive Repositories Others

Hibernate Search 4.1.0.Beta2 is released, and contains a very interesting improvement: it is now possible to precisely express which paths will be indexed when using @IndexedEmbedded.

Previously, when using @IndexedEmbedded, we would walk the entity graph up to the specified depth to index all the traversed branches. We would index to the same depth all paths, until the specified maximum depth is reached or a smaller value for depth was encountered. In a complex model it could become complex to control what exactly would get indexed.

On the forums Zach Kurey, who was having this problem, asked me just out of curiosity why we didn't provide an explicit paths-to-be-included option. Surely, he wrote, there must be a reason. Truth be told, there was no reason: we just hadn't thought about it.

So, if you have suggestions, don't think we know better. Get in touch! Our role is to protect the quality of the code and catalyse the experience of many clever users: we need to hear from you to keep on improving.

After a long discussion about the API and implementation details, this release makes the new @IndexedEmbedded(includePaths) feature available for everyone to use. Thanks to Zach and Davide D'Alto, as after contributing to the design they also provided the patches and tests, making this brilliant idea available to everyone.

How does it work?

In the following Indexed Entity we declare that when indexing each Person we want to index the name and surname fields, and its parents as well by using the well known @IndexedEmbedded annotation:

@Entity
@Indexed
public class Person {

   @Id
   public int id;

   @Field
   public String name;

   @Field
   public String surname;

   @OneToMany
   @IndexedEmbedded(includePaths = { "name" })
   public Set<Person> parents;

   @ContainedIn
   @ManyToOne
   public Person child;

    ...//other fields omitted
}

The news is the attribute includePaths of the annotation, which points out that we don't want to recursively index all fields for the parent Person, but only its name field.

This was a very simple example; the reference documentation contains more examples and details. In short, it provides better control on which fields will be indexed, avoiding to index unnecessary objects. Of course this improves overall performance.