Romain, I have about 20 BIG apps which I did run past the new version. We needed to change maybe 3 lines of code over all those apps. It's really edge cases! And we didn't totally turn around the dictionary at all. We just improved it. People likely were forced to give names manually already because it would simply not run without in the old version when a reserved word was not catched as invalid column name. Same goes for the tag handling. If someone did write a query "... and case .. when... x.bla=true" then it did just NOT work before. So people likely had to use a parameter instead. This still works, but now also the variant with using a tag does work. Again, nothing is broken which did work before...
I've deployed 3.2.0-SNAPSHOT now manually. Happy to get feedback if something is broken. LieGrue, strub > Am 24.04.2021 um 18:32 schrieb Romain Manni-Bucau <[email protected]>: > > Le sam. 24 avr. 2021 à 17:13, Mark Struberg <[email protected] > <mailto:[email protected]>> 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 <[email protected] >>> : >>> >>> What's the plan for 3.1.3 release then? >>> >>> Le sam. 24 avr. 2021 à 11:38, Mark Struberg <[email protected]> >> 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ò < >>>> [email protected]>: >>>>> >>>>> 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/>
