Rejected
Details
Assignee
UnassignedUnassignedReporter
Yoann RodièreYoann RodièreComponents
Priority
Major
Details
Details
Assignee
Unassigned
UnassignedReporter
Yoann Rodière
Yoann RodièreComponents
Priority
Created July 25, 2018 at 7:21 AM
Updated August 27, 2018 at 12:00 PM
Resolved August 27, 2018 at 12:00 PM
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 toConfigurationPropertySource
. Then allow to set one or several fallback property keys inorg.hibernate.search.v6poc.cfg.spi.KeyContext
, so that wheneverget
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.