@IndexingDependency for abstract Method

Are abstract methods supported with @IndexingDependency? This is not documented in the docs and leads to no error:

@Indexed
//(...)
public abstact class A {
    @Transient
    @GenericField
    public abstract String value();
} 
@Indexed
//(...)
public class I1 extends A {
    @Transient
    @IndexingDependency(derivedFrom = {
            @ObjectPath(@PropertyValue(propertyName = "<someotherfield>"))
    })
    public abstract String value();
} 
@Indexed
//(...)
public class I2 extends A {
    @Transient
    @IndexingDependency(derivedFrom = {
            @ObjectPath(@PropertyValue(propertyName = "<someotherfield>"))
    })
    public abstract String value();
} 

Of course for the abstract methods to make sense, queries for value are expected to work on abstract class A, class I1 and class I2 (haven’t come to test it yet -.- sorry).

They’re not “supported” in the sense that we don’t have a specific test for this, but considering the way Hibernate Search is implemented, I’d expect this to work. Give it a try?

Yep, I’m gonna try it and report back. It would be such a cool feature if it works.

1 Like

On a side note, while it may work with the model you gave in your post, it probably won’t work if another entity index-embeds A.value.

I suspect that a @IndexedEmbedded A a in another entity will lead to Hibernate Search not figuring out that A.value is derived and throwing an exception. That’s mostly because we don’t support runtime polymorphism on @IndexedEmbedded, so we need all the metadata to be present on the type targeted by @IndexedEmbedded (in this case, A). Fixing this would not be trivial, unfortunately.

I think the @IndexedEmbedded might work because all the metadata for the index should be present with the abstract method?

public abstact class A {
    @GenericField
    public abstract String value();

I’m not asking Hibernate Seach to pick up any new possible fields of I1 or I2 (like the additional childName of [HSEARCH-438] Support runtime polymorphism on associations (instead of defining the indexed properties based on the returned type) - Hibernate JIRA), but just the ones i explictly require in the base class.

Im going to try that once i have my model complete and can run some searches.

Edit: Tested it and currently does not work: Just as yrodiere said, once the abstract class is used in @IndexedEmbedded Hibernate Search again wants to check it and is not able to discover all derivedFroms.

The error is:

    Hibernate ORM mapping: 
        type 'I1': 
            failures: 
              - HSEARCH800007: Unable to resolve path '.value' to a persisted attribute in Hibernate ORM metadata. If this path points to a transient attribute, use @IndexingDependency(derivedFrom = ...) to specify which persisted attributes it is derived from. See the reference documentation for more information.
        type 'I2': 
            failures: 
              - HSEARCH800007: Unable to resolve path '.value' to a persisted attribute in Hibernate ORM metadata. If this path points to a transient attribute, use @IndexingDependency(derivedFrom = ...) to specify which persisted attributes it is derived from. See the reference documentation for more information.

I agree @IndexedEmbedded could theoretically be made to work without solving HSEARCH-438, I’m just saying currently it probably won’t. I think changes would be needed.

I opened HSEARCH-4148 to address that, but I don’t know when we’ll have time to do it.

1 Like

Thanks for even looking at it! Through the issue finally I know where the Mapping Tests are :smile: hibernate-search/integrationtest/mapper/pojo-base/src/test/java/org/hibernate/search at master · hibernate/hibernate-search · GitHub

FYI, support for polymorphic @IndexingDependency should land in 6.1: HSEARCH-4148 Polymorphic "derivedFrom" definition for derived properties by yrodiere · Pull Request #2525 · hibernate/hibernate-search · GitHub

1 Like

Support for polymorphic @IndexingDependency is there:

1 Like