I would release 3.2.0 :)
from mobile (sorry for typos ;) On Sun, Apr 18, 2021, 18:49 Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > I dont care much of this bundle naming (which looks like 3.1 since there is > no real breaking change or arch for end users) but 3.1.3 is due so if it > goes in 3.2.0 we should do a corelease of 3.1.3 with at least asm upgrade > IMHO. > > Le dim. 18 avr. 2021 à 13:08, Enrico Olivelli <eolive...@gmail.com> a > écrit : > > > 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 > > >
