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.
Comment From: mhalbritter
Thanks Jens!
Comment From: 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.
Comment From: 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.
Comment From: schauder
That sounds very reasonable. I'll give that a try.
Comment From: schauder
I used an enum utilising the standard enum conversion and left everything in Boot.
Please have another look.
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: 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.
Comment From: mhalbritter
Thanks Jens!