Dirty checking fails when searchable annotations are used on getter with 'non-standard' name


A new issue, more detailed, as suggested in HSEARCH-1076.

Hibernate search propagates entity changes to the search index(es) during an OnPostUpdate event. It checks if dirty properties are searchable, and if at least one dirty property is searchable, it builds a new document, replacing the one already in the index(es).

The 'checks if dirty properties are searchable'-part is currently failing when the following prerequisites are met:

  • There is a java field F with getter method. e.g. private string _text;

  • The getter method differs from the standard naming convention (e.g. getText for the field _text)

  • The searchable annotation is placed on the getter method

  • An entity is changed, where field F has a new value (e.g. _text is a dirty property).

It fails because it checks by using the meta data classes XClass and XProperty, and it uses XClass.getDeclaredProperties( XClass.ACCESS_PROPERTY ) to initially retrieve the names of the searchable entity properties (which are put in org.hibernate.search.engine.AbstractDocumentBuilder.PropertiesMetadata.fieldNameToPositionMap).

The problem is that XClass.getDeclaredProperties( XClass.ACCESS_PROPERTY ) returns the name extracted from the getter's method name. For the field _text used above, this means that dirty property '_text' is not linked to the extracted getter's method name 'text', and thus will not trigger a change to the search index(es).

This issue is in some form related to HHH-775, stating that getters should comply with JavaBeans spec 1.01.

This specification says in section 7.1:

GetFoo and setFoo are simply example names. Accessor methods can have arbitrary names.
However for standard naming conventions for accessor methods see the design patterns de-
scribed in Section 8.3.

So it doesn't force us to use the standard naming convention and I would argue that accessor methods may carry any name. (another example is the getter for a boolean flag, which is often in the form isEnabled())

Attached is a test case illustrating the problem.






Elmer van Chastelet


Suitable for new contributors


Pull Request


Feedback Requested



Affects versions