I'll move forward and update to 3.2.0-SNAPSHOT LieGrue, strub
> Am 19.04.2021 um 08:35 schrieb Francesco Chicchiriccò <ilgro...@apache.org>: > > On 18/04/21 12:31, Mark Struberg wrote: >> 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? >> Or is the change so subtle that we still continue with 3.1.x? > Hi Mark, > first of all, thanks for your recent (hard) work to review and close > long-standing issues. > > I don't have strong preference about versioning, but maybe 3.2.0 would report > more, to external, the idea of the amount of work done. > > Regards. > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ <http://www.tirasa.net/> > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/ <http://home.apache.org/~ilgrosso/>
