Allow to use legacy property keys in the configuration

Description

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:

  1. hibernate.search.someindex.someproperty => hibernate.search.index.someindex.someproperty

  2. hibernate.search.someOrmSpecificProperty => hibernate.search.orm.someOrmSpecificProperty

  3. 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.

Activity

Show:

Yoann RodièreAugust 27, 2018 at 12:00 PM

Closing this, because we decided we wanted to make sure users fully update their configuration when they upgrade to Search 6, in order to avoid oversights that could have dramatic impact on performance or even behavior. See HSEARCH-3266.

Rejected

Details

Assignee

Reporter

Components

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