Le sam. 24 avr. 2021 à 17:13, Mark Struberg <strub...@yahoo.de.invalid> a écrit :
> Who needs it? Most 3.1.2 users, we had several expected fixes which shouldnt trigger more than a build revalidation (and in particular not a multidb validation). > 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. > We touched dicts and mapping so i expect it to not be that transparent. At least it breaks ddl which is unexpexted > 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/> > >> > >
