Le dim. 25 avr. 2021 à 13:47, Mark Struberg <strub...@yahoo.de.invalid> a écrit :
> No, not a change. > > If an Entity had a 'double' field it was mapped to NUMERIC. Which has no > fraction digits at all > > 7.23456789d would be stored as 3. > So we can rather safely assume that people worked around this by using > float, BigDecimal, etc. > Thus no change for existing projects. > Sure that some projects use the default and do diff between snapshots and previous release ddl based on that so a change ;). > LieGrue, > strub > > > > Am 25.04.2021 um 13:39 schrieb Romain Manni-Bucau <rmannibu...@gmail.com > >: > > > > AFAIK org.apache.openjpa.jdbc.meta.MappingInfo#mergeColumn will use > > getJDBCType and in case of HSQLDB it will move from NUMERIC to BIGINTEGER > > which is a breaking change for existing apps - detail in > > https://issues.apache.org/jira/browse/OPENJPA-2648 < > https://issues.apache.org/jira/browse/OPENJPA-2648>. This kind of change > is > > fine for 3.2 but not 3.1.3 we should release IMHO. Same kind of change > > happent to SQLServer (for blob IIRC) and a few other dicts IIRC (not all > > impact DDL but it can impact the runtime and for sure impacts the dict > > customizations (not sure how important it is but it happens our dicts are > > extended to use some driver specificities). > > > > I'm not sure of the SQLServer dict usage but HSQLDB one is really used, > > even with 1.8 branch so can be neat to at least ensure this part does not > > break *by default* for next immediate release. > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau < > https://twitter.com/rmannibucau>> | Blog > > <https://rmannibucau.metawerx.net/ <https://rmannibucau.metawerx.net/>> > | Old Blog > > <http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>> > | Github <https://github.com/rmannibucau <https://github.com/rmannibucau>> > | > > LinkedIn <https://www.linkedin.com/in/rmannibucau < > https://www.linkedin.com/in/rmannibucau>> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > >> > > > > > > Le dim. 25 avr. 2021 à 13:14, Mark Struberg <strub...@yahoo.de.invalid > <mailto:strub...@yahoo.de.invalid>> a > > écrit : > > > >> 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 <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 <mailto:rmannibu...@gmail.com> > >>>>> : > >>>>> > >>>>> Le sam. 24 avr. 2021 à 17:13, Mark Struberg > <strub...@yahoo.de.invalid <mailto:strub...@yahoo.de.invalid> > >>>> <mailto: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 <mailto: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 <mailto: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/ > >
