Who needs it? For now it's not on my personal agenda as the fixes are good and moving to 3.2.0 is for me personally just a signal to our users that they should not blindly do an upgrade without a small test run first. The changes are really subtle, but again, they _might_ break in some edge cases. For vast majority of people it will be a drop in replacement.
LieGrue, strub > Am 24.04.2021 um 13:16 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > What's the plan for 3.1.3 release then? > > Le sam. 24 avr. 2021 à 11:38, Mark Struberg <strub...@yahoo.de.invalid> a > écrit : > >> 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/> >>
