There is a bug in hibernate search (fixed in 3.4.2) where changes are not reflected in the index when a member of a collection of an entity changes. See HSEARCH-1020.

But for WebDSL, the problem seems that any update to any entity is not reflected in the search index.

For example, if I change the description of this very issue, the changes will not be searchable when searching for this issue.
edit: searching for test123 will not find this issue.

This might have to do with an event listener that is not triggered/disabled for some reason. Needs investigation!

Submitted by Elmer van Chastelet on 21 March 2012 at 16:42

The same problem arises in the researchr project, but in my example weblib application it works correctly.

I’ve put a println on entry and exit of our SetVersionSaveOrUpdateEventListener, and I noticed that the yellowgrass and researchr apps show two occurrences of repeated calls next to each other (tested with updated hibernate search 3.4.2):

...
** IN: SetVersionSaveOrUpdateEventListener.onSaveOrUpdate
** IN: SetVersionSaveOrUpdateEventListener.onSaveOrUpdate
** OUT: SetVersionSaveOrUpdateEventListener.onSaveOrUpdate
** OUT: SetVersionSaveOrUpdateEventListener.onSaveOrUpdate
...

In my weblib application (where changes are successfully propagated to index), it only shows one execution at a time:

...
** IN: SetVersionSaveOrUpdateEventListener.onSaveOrUpdate
** OUT: SetVersionSaveOrUpdateEventListener.onSaveOrUpdate
** IN: SetVersionSaveOrUpdateEventListener.onSaveOrUpdate
** OUT: SetVersionSaveOrUpdateEventListener.onSaveOrUpdate
...

Maybe this hinders hibernate search from updating the index.

ps. on a single homepage view of researchr, this eventlistener, together with the SetValidationEventListener are executed 2956 times. And on changing a publication’s abstract 34892 times. Don’t know if that’s normal.

The issue seems not related to the observation in my previous comment. The same problem arises in a very simple web application I used to fine tune ‘more-like-this’ parameters for plagiarism detection (see attachment), which doesn’t show the consecutive calls. Changing the text of an Assignment will not change its indexed terms, so the root page will not show the assignment itself in its search results after changing the text.

Hibernate search doesn’t seem to update the index on change of a simple property (like String, i.e. webdsl’s wiki-text/text/…), but does this if a collection (and probably a reference property) gets changed.

This explains why adding a comment in Yellowgrass will update the index for the Issue. (Comment entity is added to Issue.log -> List)

This also explains why it did seem to work for weblib. In the edit form I used, there is a input element on a collection property, and therefore the collection is renewed and thus the index is updated for the updated entity.

I managed to find the problem. The hibernate search annotations were put on the property-getters in generated entity class. For each entity property (e.g. text), a field is generated with the name of the property prefixed with ‘_’ (e.g. _text, while the getter is named getPropertName (e.g. getText()). The reflection manager of hibernate generates metadata classes, and uses the name of the getter to determine the field for which it returns the value based on the name of the getter, and thus the underscore is ignored, leading to a mismatch during dirty checking of properties in the FullTextIndexEventListener (_text is not matched with text), i.e. no update to index triggered.

Fixing this particular issue is as simple as moving the search annotations to the field instead of the getter. But there might be more issues related to mismatches between field and property names.

Fixed in r4973