Index manager type is required

Hibernate Search
1

Hi all,

I’m trying to update Hibernate Search in our app from version 5.5.8.Final to 5.9.2.Final and after starting app I’m getting following exception:

HSEARCH000306: Index manager type is required to build a field bridge for coordinate in org.hibernate.search.spatial.Coordinates

The mapping on the class looks like this:

@Transient
@Spatial(spatialMode = SpatialMode.HASH, name = "coordinate")
@SortableField(forField = COORDINATE)
Coordinates getCoordinate() {
    if (this.location == null || location.getPosition() == null) {
        return null;
    }
    Coordinate coordinate = GeometryUtil.getGlobalCoordinates(this.location.getPosition());
    return Point.fromDegrees(coordinate.y, coordinate.x);
}

I do not know how should I exactly configure the type of IndexManager (it was not needed until upgrade of the library). I have also checked documentation but setting this property hibernate.search.[default|].indexmanager = near-real-time had no effect.

Not sure which other information should I provide to you so it is easier for you to identify my problem.

Any idea what is the problem?

Thank you.

2

The only way I can see this happening is if you use a custom index manager which implements its org.hibernate.search.indexes.spi.IndexManager#getIndexManagerType method by returning null… Do you use a custom IndexManagerFactory that affects a different implementation to the near-real-time index manager?

If not, please give us the full stack trace, or even, if possible, the full startup log in a pastebin. The full content of hibernate.properties could be useful too. Don’t forget to edit out sensitive information such as URLs and passwords.

3

Thank you for your reply.

No we do not use any custom IndexManager or IndexManagerFactory.

Here are properties we use to configure Hibernate:

"hibernate.search.default.directory_provider" -> "org.hibernate.search.store.impl.RAMDirectoryProvider"
"hibernate.search.default.refresh" -> "300"
"hibernate.search.enable_dirty_check" -> "false"
"hibernate.dbcp.whenExhaustedAction" -> "0"
"hibernate.cache.region.factory_class" -> "org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory"
"hibernate.cache.use_second_level_cache" -> "false"
"hibernate.show_sql" -> "false"
"hibernate.hbm2ddl.auto" -> "create-drop"
"hibernate.search.autoregister_listeners" -> "true"
"hibernate.cache.use_query_cache" -> "false"
"hibernate.spatial.dialect" -> "org.hibernate.spatial.dialect.h2geodb.GeoDBDialect"
"hibernate.format_sql" -> "false"
"hibernate.search.similarity" -> "ch.local.repositoryutil.sql.hibernatesearch.NotCountingSimilarity"
"hibernate.search.default.worker.backend" -> "lucene"
"hibernate.connection.isolation" -> "2"
"hibernate.current_session_context_class" -> "org.springframework.orm.hibernate5.SpringSessionContext"
"hibernate.cache.provider_configuration_file_resource_path" -> "classpath:/config/ehcache/ehcache.xml"
"hibernate.dialect" -> "org.hibernate.spatial.dialect.h2geodb.GeoDBDialect"

It is a copy from Map since we are not using hibernate.properties file and here is pastebin with full startup log.

4

Looks like you found a bug. I filed HSEARCH-3339 and will try to come up with a fix.

Thank you very much for taking the time to give us all the necessary information! Things are much easier that way…

I think a workaround would be to annotate the contained entity with @Indexed. It has obvious downsides, in particular it will degrade performance since indexes will be kept up to date for no reason, but at least it should allow you to continue to work on your migration until we released a fix.

5

I’m glad I could help and thank you for the workaround, it works.

Just one more question. The class which has this coordinate is abstract, here is definition:

@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(
    name="type",
    discriminatorType=DiscriminatorType.STRING
)
@Table(name="geo_place")
@Cache(usage=CacheConcurrencyStrategy.READ_WRITE)
@AttributeAccessor("property")
@TypeDefs({
	@TypeDef(defaultForType=LocalUID.class, typeClass=LocalUIDUserType.class),
	@TypeDef(defaultForType=DateTime.class, typeClass=JodaTimeUserType.class)
})
@AnalyzerDefs({
  @AnalyzerDef(name = "placeNameAnalyzer",
    tokenizer = @TokenizerDef(factory = StandardTokenizerFactory.class),
    filters = {
      @TokenFilterDef(factory = ASCIIFoldingFilterFactory.class),
      @TokenFilterDef(factory = LowerCaseFilterFactory.class),
      @TokenFilterDef(factory = WordDelimiterFilterFactory.class)
    })
})
public abstract class Place implements LocalEntity {
    /**
	 * common impl ....
	 */
}

Can @Indexed on this class cause some problems for concrete implementations of this class? The concrete implementations already have @Indexed on them.

6

No, @Indexed on an abstract class shouldn’t cause any problem. As far as I remember, it will mostly get ignored. As a matter of fact, it was necessary in some older versions of Hibernate Search to work around another bug related to @ContainedIn.

The only change is that it will work around your bug (probably) and also it will set the default name of the index of any subclass to com.yourcompany.Place. If you don’t want that, you can set the name of the index of each subclass explicitly using @Indexed(index = ...).

7

Great, thank you for your help.

8

@Jaro, we just released 5.9.3.Final (as well as 5.10.4.Final), which includes a fix for this problem. You should be able to get rid of this extra @Indexed by upgrading.

You can find the release announcement here.

9

Thank you for the info, I have test it and it fixed my issue. Again thank you very much for your help :+1:

1 Like