Perform Elasticsearch schema re-creation or validation when starting in tests/dev mode with Hibernate Search and Elasticsearch dev services

[yrodiere]

Description

In recent versions of Quarkus, Hibernate ORM schema management defaults to "drop and create" when using dev services.
The goal is to ensure that dev services always start from a clean state.

Also in recent versions of Quarkus, Quarkus will perform database schema validation when starting in dev mode by default, regardless of the schema management configuration.

We should do the same for Hibernate Search in dev mode.

Implementation ideas

See io.quarkus.hibernate.orm.runtime.schema.SchemaManagementIntegrator, io.quarkus.hibernate.orm.runtime.HibernateOrmRuntimeConfigPersistenceUnit.HibernateOrmConfigPersistenceUnitDatabaseGeneration#generation.

See io.quarkus.hibernate.orm.deployment.HibernateOrmProcessor#warnOfSchemaProblems, io.quarkus.hibernate.orm.deployment.HibernateOrmConfigPersistenceUnit#validateInDevMode.

[quarkus-bot]

/cc @gsmet, @loicmathieu, @stuartwdouglas

[yrodiere]

Actually... we default to create-or-validate for schema management in Hibernate Search, which works just fine with Dev Services already: Dev Services always lack the index when they start, so Hibernate Search will simply initialize the schema on a newly created Elasticsearch container.

As for validating the schema in dev mode, even in the ORM extension it's disabled automatically as soon as the user sets quarkus.hibernate-orm.database.generation explicitly. In Hibernate Search, by default we will validate the index if it exists, and if the property is set we'll do whatever the property tells us to do.

So we're already behaving like the Hibernate ORM extension. Closing.

[yrodiere]

Actually, this is also about tests... and in the case of tests, we start the application multiple times for the same Elasticsearch container, so setting schema management to drop-and-create-and-drop does matter.

Validation still isn't useful, though.