Dialect.GetCastTypeName takes a SqlType, disregards the type Length/Precision/Scale and use instead Column.DefaultLength/Column.DefaultPrecision/Column.DefaultScale, which are 255/19/2.
A default scale of 2 is quite debatable for decimal, but it does not get used in fact due to a bug: the type resolution currently compares provided length with the max for the type, which is well below 255 for decimal, so it always uses the default for decimal type, like decimal(19,5) with SqlServer2000Dialect.
Moreover, is such a hard-coded string limitation to a 255 length really sound in a modern library?
decimal registration for a number of dialects now correctly use precision and scale instead of having one dimension hard-coded and the other set as the length.
decimal max precision for dialects is now taken into account and limited to the smallest between the database capacity and the .Net capacity (which is 28).
default cast for decimal was decimal(19,5) and will now be decimal(28,10), trim down to database capacity if required.
Frédéric Delaporte October 3, 2017 at 9:02 PM
Edited
The cast to decimal(19,5) wrecking the queries of likely uses this function. That is the case, the HQL cast function relies on this method.
I think we should change it to handle defined length/precision/scale if any, otherwise use configurable defaults. ( may still be solved by avoiding the cast.)
Dialect.GetCastTypeNametakes aSqlType, disregards the typeLength/Precision/Scaleand use insteadColumn.DefaultLength/Column.DefaultPrecision/Column.DefaultScale, which are255/19/2.A default scale of
2is quite debatable fordecimal, but it does not get used in fact due to a bug: the type resolution currently compares provided length with the max for the type, which is well below255fordecimal, so it always uses the default fordecimaltype, likedecimal(19,5)withSqlServer2000Dialect.Moreover, is such a hard-coded string limitation to a
255length really sound in a modern library?