what would it take to get rid of Dialect.getSqlTypeDescriptorOverride() ?

[gavinking]

I really hate Dialect.getSqlTypeDescriptorOverride(), and I highly suspect that at least some of the overrides that exist in the Dialects either aren't necessary or could be done in a different way.

Indeed, as I understand it, a lot of those overrides are there only to make schema update/validation work when the db doesn't distinguish natively between two JDBC types. And it seems to me that replacing the whole type descriptor is just not the best way to solve that problem.

At the very least, can't this be handled via contributeTypes() instead? Why do we have two ways of doing what looks like much the same thing?

[sebersole]

I totally I agree. The remapping API stuff was just the way I could backport these remapping ideas from 6 (really even the "pre work" for 6) to fit within restrictions of compatibility.

But that stuff could and should just go away.

[gavinking]

I think that would be a good start, but on the other hand I don't want to just swap type overrides for type contributions. I think we should also review what's there and if they're really necessary. It's a little tricky because the overrides that are there today don't do a good job of documenting what their purposes are.

[sebersole]

The contributions are actually exactly the correct replacement for the legacy remapping.

I can't say if the Dialects themselves do a good job documenting why they register/contribute certain overrides, but they absolutely should

[gavinking]

What I mean is if for example one of them is not necessary at all, or only there to e.g. make schema validator happy, I would prefer to remove it / replace it with a different solution.

[sebersole]

considering the dialect also defines its exporter for schema export, i think that's reasonable

[sebersole]

come to think of it... we should probably have dialect provide similar for how to do validation and update as well for the some of the same reasons