Le sam. 24 avr. 2021 à 22:08, Mark Struberg <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/ > > > >