No, the DDL remains the same. We just switched to using java.time types in Oracle natively on the JDBC level. But the type names stood the same.
LieGrue, strub > Am 24.04.2021 um 22:41 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > Le sam. 24 avr. 2021 à 22:08, Mark Struberg <strub...@yahoo.de.invalid > <mailto:strub...@yahoo.de.invalid>> a > écrit : > >> 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. >> > > Some keywords change make the generated ddl different now IIRC. > This is the part i had in mind which is a blocker to upgrade since ddl are > no more stable. > Not all were forced to be changed for ddl generation - depends driver/db > version. > Dont recall if it was about hsqldb or another one but dont think we can > release it without a 3.1.3. > Doing a subdict keeping old one can mitigate it and enable to bypass 3.1.3. > > >> LieGrue, >> strub >> >> >>> Am 24.04.2021 um 18:32 schrieb Romain Manni-Bucau <rmannibu...@gmail.com >>> : >>> >>> Le sam. 24 avr. 2021 à 17:13, Mark Struberg <strub...@yahoo.de.invalid >> <mailto: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/
