Suggestion : raise an exception when HSearch annotation is present on unrecognized method

Hibernate Search
1

Hi searchers,

I did a lot of indexation yet. And I met a use case that not satisfied me a lot : the “error” may be silent.
Indeed, when you simply annotate a method, with unconventional naming, you have to think that all your HSearch annotations on this method are ignored.
The method’s name must start with “isXXX” or “getXXXX”. I annotated for example this method :

@GenericField
    @IndexingDependency(derivedFrom = {
            @ObjectPath({@PropertyValue(propertyName = Acte_.REPRISE)}),
            @ObjectPath({@PropertyValue(propertyName = Acte_.ACTE_MICEN), @PropertyValue(propertyName = ActeMicen_.SYNCHRONISE)})
    })
public boolean mustBeMicenSynchronized() {
        return this.acteMicen != null
                && Boolean.TRUE.equals(this.getReprise())
                && !Boolean.TRUE.equals(this.acteMicen.getSynchronise());
    }

instead of doing like this :

public boolean mustBeMicenSynchronized() {
        return this.acteMicen != null
                && Boolean.TRUE.equals(this.getReprise())
                && !Boolean.TRUE.equals(this.acteMicen.getSynchronise());
    }

@GenericField
    @IndexingDependency(derivedFrom = {
            @ObjectPath({@PropertyValue(propertyName = Acte_.REPRISE)}),
            @ObjectPath({@PropertyValue(propertyName = Acte_.ACTE_MICEN), @PropertyValue(propertyName = ActeMicen_.SYNCHRONISE)})
    })
public boolean isMustBeMicenSynchronized() {
        return mustBeMicenSynchronized();
    }

So no error at present. The mass indexer do its job.
Moreover, I never query on this field named “mustBeMicenSynchronized” as I expect. So all is good. (although this index property never exist).
I did then my complex query, it results my projection object mapping the response.
This object never receive a “MustBeMicenSynchronized” property, so no mapping and it will be always null…always that the problem. In fact, the property was never indexed, my test :

If (Boolean.TRUE.equals(mustBeMicenSynchronized)) {
//...some operations
}

will be always false. The error was at indexation time.

What do you think of it ?

2

Hi,

Thanks for your feedback. That’s a good idea, I created [HSEARCH-4344] Log a warning or throw an error for Hibernate Search annotations on methods with unsupported name or arguments - Hibernate JIRA to track it.

Of course the problem will be the implementation; we ignore such method for a reason, and the reason is the underlying library used to retrieve a list of properties (Hibernate Commons Annotations) simply ignores such methods. In order to detect the problematic methods, we would have to bypass that library and actively look for ignored methods, then look for Hibernate Search properties on those methods…

Anyway, whoever works on that will have to be creative :slight_smile:

3

In the same idea, what do you think about “raise an exception when querying on a never indexed field” ?
Typically, the exists predicate clause will return false which is technically right, but semantically can be unexpected behavior
It can happen when refactoring, and bug become silent.

4

If you use the Hibernate Search DSL, you will get exceptions when targeting fields that haven’t been declared, i.e. because of a typo.

Note that if you’re using dynamic field templates, that protection obviously goes away, because there’s no way to know that a field name matching a certain template is actually a typo.

As to throwing an exception when targeting a field with no indexed data… I don’t think it’s a good idea, because there are perfectly valid use cases where an index doesn’t contain any data for a given field… yet.

To avoid problems with refactoring, a better solution IMO would be the generation of a static metamodel, similar to the JPA metamodel generator. That would, however, require a large amount of work, unless we stick to simply generating constants with field names. Also, that wouldn’t help with dynamic fields.