Review names and composition of configuration properties

Description

For example the worker related properties should be split among those which are global and those which are applied to the specific backend executors.

Also we might want to rename indexing.synchronization-strategy to automatic-indexing.synchronization.strategy, to be consistent with lifecycle.strategy in the Elasticsearch backend. Same for other strategies, for example multi-tenancy strategies.

Also, as mentioned here, we might want to add prefixes for configuration properties that are only valid for a certain type of backend/directory/... . For example:

  • hibernate.search.backend.myBackend.directory.root would become hibernate.search.backend.myBackend.directory.local_filesystem.root

  • hibernate.search.backend.myBackend.directory would become hibernate.search.backend.myBackend.lucene.directory

  • and so on.

This has the serious disadvantage of making the property longers, though, and the usefulness of this added verbosity is doubtful, since a backend/directory/etc. only ever has one type and only ever accepts a single set of sub-properties. I would be against that, but let's discuss it if there are strong arguments in favor of it...

Environment

None

Status

Assignee

Yoann Rodière

Reporter

Sanne Grinovero

Labels

None

Suitable for new contributors

None

Feedback Requested

None

Components

Fix versions

Priority

Major
Configure