Since we're going to rename several properties as part of HSEARCH-859, and several others just because of the overall architectural changes in Search 6 (introduction of a separate representation of backends that can be parameterized, in particular), configuring Search 6 may be a bit difficult when migrating from Search 5. Let's try to make that easier.
The idea would be, when we can't find a value for a property, to fall back to the legacy name of that property, and to log a warning telling users their configuration uses deprecated configuration properties.
Several use cases:
# hibernate.search.someindex.someproperty => hibernate.search.index.someindex.someproperty # hibernate.search.someOrmSpecificProperty => hibernate.search.orm.someOrmSpecificProperty # hibernate.search.someindex.someProperty => hibernate.search.index.someindex.someRenamedProperty
How to implement that is not immediately obvious:
* The solution must print the full property key in the warning, not just the radical. So we can't implement it in the ConfigurationProperty class, at least not *only* there. * As seen in example 3 above, the solution must work with both structural renamings like the addition of a ".index." prefix, and radical renamings
We could implement a multiple solution:
* To handle structural renamings, Offer a way to add a fallback *with a warning* to a ConfigurationPropertySource. The resulting property source would print a warning each time it needs to use the fallback. * To handle radical renamings, either: ** add a {{getWithFallback(Consumer<String> fallbackListener, String mainKey, String ... fallbackKeys)}} method to {{ConfigurationPropertySource}}. Then allow to set one or several fallback property keys in {{org.hibernate.search.v6poc.cfg.spi.KeyContext}}, so that whenever {{get}} is called on the resulting property, {{getWithFallback}} is called on the configuration property source. ** OR carefully add wrappers to some configuration property sources that carry a list of property keys and what they should fall back to.
We'll need to test it, and test it well... In particular double renamings as shown in example 3.
|
|