Mark, Il giorno dom 18 apr 2021 alle ore 12:31 Mark Struberg <strub...@yahoo.de.invalid> ha scritto: > > Hi folks! > > We fixed a lot of tickets since the last release. Some of them also > change/fix the behaviour slightly. There are a few main tickets which do not > introduce a big change, but might very subtly break existing apps in very > rare edge cases: > > * UnaryOp now respects the target type. For doing that I had to also change > the Raw handling, finally fixing a bug that got introduced in 2009 ;) Before > this fix all UnaryOps (SUM, MIN, MAX, CASE, etc) did return the native type > coming from the JDBC driver. That means that for a TIME WITH TIME ZONE field > we even did return vendor specific jdbc types like com.microsoft.jdbc.* or > com.oracle.* types, etc. > > This mainly affects 2 areas: First, if there is a select sum, max, min, case, > etc which is used to return an Object[] and then cast up to the type. This > might now fail, because we now return the correct type defined in the field. > E.g. if one did do a "select max(f.localDateTimeField) from ..." then this > used to return a driver specific type for many databases as described above. > After the fix, we now return the type of the 'localDateFimeField', in this > case java.time.LocalDateTime. > > Same happens for "select NEW" because right now we only look for a perfectly > matching constructor and do no coercing. Should we introduce coercing > probably? Means if a select new will result in a float value but there is > only a constructor for double, do we want to also accept it in the future? > > * Along the way I also implemented BooleanRepresentation handling for SQL > literals via DBDictionary. > > > * respect TIMESTAMP precision in Oracle. Due to a bug we did hardcoded round > at 3 digits precision. So we essentially only allowed millis, even on a > TIMESTAMP(6) field. The new code does respect the second fractions and now > defaults to 6. It should be compatible but it might behave very subtle > different. > > * fix the reserved column name handling by introducing ColumnIdentifierRule > (using the invalidColumnWordSet from the DBDictionary being used), separating > it from the ColumnDefIdentifierRule. > > * fix SUM to always return Double as requested by the spec. Previously we did > return whatever Numeric the JDBC driver did serve, resulting in non portable > code. > > * PostgreSQL now supports setQueryTimeout. User might see this come alive and > now return different when the situation occurs. > > > Does all that mean we should rather call the release 3.2.0 rather than 3.1.3?
It makes sense to me to call this new release 3.2.0 just my 2 cents Enrico > Or is the change so subtle that we still continue with 3.1.x? > > LieGrue, > strub
