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/> >
