broken before, broken afterward. Sorry that is not a use case which justifies tons of effort on our side.
LieGrue, strub > Am 25.04.2021 um 14:08 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > Le dim. 25 avr. 2021 à 13:47, Mark Struberg <strub...@yahoo.de.invalid > <mailto: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/
