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

Reply via email to