Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

PropertyBridge on property marked with @IndexingDependency(derivedFrom = ...) leads to bootstrap failure

Description

For example in the tests of the Search 5 migration helper, we have something like this:

@Entity @Indexed public class POI { @Id @Field(store = Store.YES) @Field(name = "idSort") @SortableField(forField = "idSort") Integer id; ... Double latitude; Double longitude; @Spatial(store = Store.YES) @Transient @IndexingDependency(derivedFrom = { @ObjectPath(@PropertyValue(propertyName = "latitude")), @ObjectPath(@PropertyValue(propertyName = "longitude")) }) public Coordinates getLocation() { return new Coordinates() { @Override public Double getLatitude() { return latitude; } @Override public Double getLongitude() { return longitude; } }; } ... }

@Spatial applies a bridge to the Coordinates object returned by getLocation(), marking its getLatitude() and getLongitude() methods as indexing dependencies. But getLocation() is also marked as derived from other properties...

And we get that kind of failure:

Hibernate ORM mapping: type 'org.hibernate.search.test.spatial.POI': failures: - HSEARCH800007: Path '.location' cannot be resolved to a persisted value in Hibernate ORM metadata. If this path points to a transient value, use @IndexingDependency(derivedFrom = ...) to specify which persisted values it is derived from. See the reference documentation for more information.

The cause seems to be that we take derivedFrom into account only when a dependency is declared to the property values directly, not when a dependency is declared to nested properties.

I believe that, as long as all the dependencies involved are not entities, we should simply ignore all dependencies to nested properties:

  • When an entity is involved at any point, then it's possible that ignoring the dependency might result in problems, so we'd better throw an exception.

  • But as long as all dependencies are non-entities, we can assume they are not managed and were simply built as the result of a calculation. And we supposedly already know all the dependencies of that calculation thanks to derivedFrom.

Activity

Show:
Fixed

Details

Assignee

Reporter

Components

Sprint

Fix versions

Priority

Created September 9, 2020 at 2:19 PM
Updated October 8, 2020 at 12:30 PM
Resolved September 11, 2020 at 8:24 AM