Dirty checking fails when searchable annotations are used on getter with
'non-standard' name
--------------------------------------------------------------------------------------------
Key: HSEARCH-1078
URL:
https://hibernate.onjira.com/browse/HSEARCH-1078
Project: Hibernate Search
Issue Type: Bug
Components: mapping
Affects Versions: 4.1.0.CR2, 3.4.2
Reporter: Elmer van Chastelet
Attachments: TestEntityChangeWithDifferentGetterName.zip
A new issue, more detailed, as suggested in
[
HSEARCH-1076|https://hibernate.onjira.com/browse/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|https://hibernate.onjira.com/browse/HHH-755], stating that getters should comply
with JavaBeans spec 1.01.
This specification says in section 7.1:
{quote} 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.
{quote}
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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira