Provides a way for configuring after the datasource is initialized

[refeccd]

In the current version, the datasource can only be initialized through configuration, and the properties cannot be modified after initialization.
Although it is possible to modify datasource properties through BeanPostProcessor, do you want to add a more convenient method, such as Customizer callback?

[wilkinsona]

Thanks for the suggestion. Unfortunately, I don't understand the benefit that a customizer callback would bring. Can you please provide an example of what you would like to be able to do and explain why it isn't possible at the moment?

[refeccd]

here is the example https://github.com/liaozan/datasource-customizer-suggestion.git

[refeccd]

example updated

[wilkinsona]

Thanks for the example.

You can already configure the DataSource in this way using configuration properties. For example, spring.datasource.hikari.datasourceproperties.example=alpha will result in the dataSourceProperties of the auto-configured HikariDataSource containing the key example and the value alpha. Assuming that the @Bean method for a DruidDataSource is annotated with @ConfigurationProperties("spring.datasource.druid"), you could do something similar with spring.datasource.druid.connectproperties.example=alpha.

Have you considered using this approach rather than a bean post-processor or you suggested customizer callback? As things stand, I can't see much, if any, benefit of the customizer callback over what's already supported.

[refeccd]

If I want to provide a unified approach instead of do it in every service ，how to do it?
If the configuration is configured in the configuration file, then the user needs to be familiar with the configuration method of each datasource. If you switch to another data source, you need to reconfigure it, and there may be errors, such as spelling errors and inconsistent attributes. If you provide a callback, you can standardize the behavior in a unified third-party starter, shielding the underlying details

[wilkinsona]

If I want to provide a unified approach instead of do it in every service ，how to do it?

A starter can either use a bean post-processor as I suggested above or it can provide the properties for different types of DataSource via an EnvironmentPostProcessor that adds a PropertySource. We'd like to improve the mechanism (#24688) for contributing application properties from a starter, but this is how I'd implement this at the moment.

I'll flag this for team attention to see if the rest of the team feel that a customizer callback is warranted here.

[philwebb]

I think there's a danger that we could over do the Customizer callbacks if we're not careful. It feels like this use-case isn't all that common so I think the BeanPostProcessor is probably the best approach.

[refeccd]

Well, I 've implemented it with a BeanPostProcessor