Add property spring.data.jdbc.dialect

[schauder]

The class valued property allows to configure a dialect to use for Spring Data JDBC, without relying on a database connection to determine it.

This is useful especially for CDS.

[mhalbritter]

Thanks Jens!

[mhalbritter]

Sorry, after some discussion I had to revert the merge.

First, because we don't really like having Class configuration properties, it's not very user-friendly having to configure a fully-qualified class name.

Second, this doesn't work in a native image without reflection hints. Sometimes they're unavoidable, but we'd like to explore if there's a way around that.

[wilkinsona]

I wonder if we can do something similar to our spring.jpa.database property that's backed by the org.springframework.orm.jpa.vendor.Database enum? Perhaps a somewhat similar enum, either in Boot or Spring Data Relational, that provides mappings of database name to dialect. This mapping could be similar to what's already done in org.springframework.data.jdbc.repository.config.DialectResolver.DefaultDialectProvider.getDialect(Connection), but instead of using the database product name from the connection as the input, it'd be the value from the new enum.

[schauder]

That sounds very reasonable. I'll give that a try.

[schauder]

I used an enum utilising the standard enum conversion and left everything in Boot.

Please have another look.

[wilkinsona]

Thanks for the update, @schauder. Did you consider adding the enum to Spring Data Relational? To me, that feels like a more natural home for it and it would make it easier to keep it in sync with the dialect implementations.

[schauder]

Yes, I did consider moving it to Spring Data JDBC.
While I agree that it might be easier to sync it to changes in Spring Data, I do think it belongs more on the Boot side of things, since Boot is responsible for handling application.properties and similar and the Enum exists only for that purpose.

That said: If you want it out of Boot, I don't have a problem with moving it into Spring Data.

[wilkinsona]

I don't feel strongly about this, just trying to reduce duplication overall.

I wondered if the enum could also support the mapping that's currently done by DefaultDialectProvider.getDialect through a fromMetadata(DatabaseMetaData) static method. That would leave us with a single place in both codebases that knows about all of the different dialects.

If you think that's likely to be more trouble than it's worth, we can keep the enum in Boot.

[schauder]

If you think that's likely to be more trouble than it's worth, we can keep the enum in Boot.

Then let us keep it in Boot.

[mhalbritter]

Thanks Jens!