Enable multiple SQL dialects for multiple datasources

[kota65535]

Related to: #544

As commented in #544 (comment), currently we cannot use different SQL dialects for multiple repositories because there is no way to configure JdbcConverter bean definition for repositories of each datasource.

One possible solution is to add jdbcConverterRef parameter to @EnableJdbcRepositories, like existing jdbcOperationRef, transactionManagerRef, etc.

[mp911de]

We should allow specifying the JdbcAggregateTemplate that encapsulates data source, dialect, and other related resources.

[kota65535]

@mp911de Thank you for your reply.
You mean adding a jdbcAggregateTemplateRef annotation or something to @EnableJdbcRepositories?
Maybe the implementation goes with changing JdbcRepositoryFactory constructor to accept a JdbcAggregateTemplate bean directly, and then remove encapsulated beans (converter, dialect, operations).
But we also have to create JdbcQueryLookupStrategy instance here which also depends on encapsulated beans (converter, dialect, operations).
How should we create it? Should we make encapsulated beans of JdbcAggregateTemplate accessible and reuse them?

[schauder]

Yes, @EnableJdbcRepositories should get an attribute jdbcAggregateOperationsRef. Other ..Refs should be obtained from the JdbcAggregateOperations.
Adding getters for that purpos is fine.
...ref attributes of @EnableJdbcRepositories should get deprecated.

[AnatoliyYakimov]

I think it wold be good decision to simplify overall configuration of Data Jdbc from end user side. For now it has very complex structure of beans that should be defined with circular dependencies between them.
Maybe we could simplify this configuration to single builder like this:

DataAccessStrategy strategy = DataAccessStrategy.builder()
    .dataSource(datasource) //We can create NamedParameterJdbcTemplate from DataSource internally
    .dialect(dialect) //Also we can infer dialect from DataSource
    .customConversions(conversions) 
    .entitiesPackage("com.example.entity")
    .build()
JdbcAggregateTemplate = new JdbcAggregateTemplate(strategy); //Works as JdbcTemplate and DataSource 

Thats pretty much it for configuration, that user really need to know about library.

Also i think that DataAccessStrategy is better candidate to "God-object" role than JdbcAggregateTemplate. In Spring Template object only provide simplified API for different actions like:

• JdbcTemplate
• RestTemplate
• KafkaTemplate
• RetryTemplate
• etc.
  No one of this objects is god-object or orchestrator object.