You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Mark Struberg <st...@yahoo.de.INVALID> on 2021/04/18 10:31:36 UTC
[DISCUSS] next up 3.1.3 or 3.2.0?
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?
LieGrue,
strub
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Ok, took time to test HSQLDB case, it really breaks existing DDL handling
but runtime by itself is ok-ish so I tend to think the doc must be prepared
and proposed with the vote but will be enough since there will be more
build surprises than runtime surprises in practise thanks the auto
adjustment of the type mapping.
wdyt?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le dim. 25 avr. 2021 à 15:35, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
>
>
> Le dim. 25 avr. 2021 à 14:31, Mark Struberg <st...@yahoo.de.invalid> a
> écrit :
>
>> broken before, broken afterward. Sorry that is not a use case which
>> justifies tons of effort on our side.
>>
>
> Tons as stashing a line? ;)
> Im fine if we do the 3.1.3 and 3.2.0 at the same time, does not require
> more efforts if done this way IMHO.
> We can also investigate the doc (not only jira which is never read by
> users) option (didnt test if it was configurable in the unit props but i
> assume so) and highlight it properly on the announcement (like a "danger"
> banner).
> But we must focus on users and not us IMHO so we must have a solution to
> limit properly user breaking changes on used features whatever we like it
> or not and even when we assume we made it better like here IMHO.
> Also note that you assume it was broken but tons of apps work well limited
> to int (vs long).
>
> Im fine with both options but im not fine we swallow it silently.
>
>
>> LieGrue,
>> strub
>>
>> > Am 25.04.2021 um 14:08 schrieb Romain Manni-Bucau <
>> rmannibucau@gmail.com>:
>> >
>> > Le dim. 25 avr. 2021 à 13:47, Mark Struberg <struberg@yahoo.de.invalid
>> <ma...@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 <
>> rmannibucau@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 <struberg@yahoo.de.invalid
>> >> <ma...@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 <
>> >> rmannibucau@gmail.com
>> >>>>> :
>> >>>>>
>> >>>>> Le sam. 24 avr. 2021 à 22:08, Mark Struberg
>> <struberg@yahoo.de.invalid
>> >>>> <mailto:struberg@yahoo.de.invalid <mailto:struberg@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 <
>> >>>> rmannibucau@gmail.com <ma...@gmail.com>
>> >>>>>>> :
>> >>>>>>>
>> >>>>>>> Le sam. 24 avr. 2021 à 17:13, Mark Struberg
>> >> <struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>
>> >>>>>> <mailto:struberg@yahoo.de.invalid <mailto:
>> struberg@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 <
>> >>>>>> rmannibucau@gmail.com <ma...@gmail.com>
>> >>>>>>>>> :
>> >>>>>>>>>
>> >>>>>>>>> What's the plan for 3.1.3 release then?
>> >>>>>>>>>
>> >>>>>>>>> Le sam. 24 avr. 2021 à 11:38, Mark Struberg
>> >>>> <struberg@yahoo.de.invalid <ma...@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ò <
>> >>>>>>>>>> ilgrosso@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/
>>
>>
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le dim. 25 avr. 2021 à 14:31, Mark Struberg <st...@yahoo.de.invalid> a
écrit :
> broken before, broken afterward. Sorry that is not a use case which
> justifies tons of effort on our side.
>
Tons as stashing a line? ;)
Im fine if we do the 3.1.3 and 3.2.0 at the same time, does not require
more efforts if done this way IMHO.
We can also investigate the doc (not only jira which is never read by
users) option (didnt test if it was configurable in the unit props but i
assume so) and highlight it properly on the announcement (like a "danger"
banner).
But we must focus on users and not us IMHO so we must have a solution to
limit properly user breaking changes on used features whatever we like it
or not and even when we assume we made it better like here IMHO.
Also note that you assume it was broken but tons of apps work well limited
to int (vs long).
Im fine with both options but im not fine we swallow it silently.
> LieGrue,
> strub
>
> > Am 25.04.2021 um 14:08 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Le dim. 25 avr. 2021 à 13:47, Mark Struberg <struberg@yahoo.de.invalid
> <ma...@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 <
> rmannibucau@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 <struberg@yahoo.de.invalid
> >> <ma...@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 <
> >> rmannibucau@gmail.com
> >>>>> :
> >>>>>
> >>>>> Le sam. 24 avr. 2021 à 22:08, Mark Struberg
> <struberg@yahoo.de.invalid
> >>>> <mailto:struberg@yahoo.de.invalid <mailto:struberg@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 <
> >>>> rmannibucau@gmail.com <ma...@gmail.com>
> >>>>>>> :
> >>>>>>>
> >>>>>>> Le sam. 24 avr. 2021 à 17:13, Mark Struberg
> >> <struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>
> >>>>>> <mailto:struberg@yahoo.de.invalid <mailto:struberg@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 <
> >>>>>> rmannibucau@gmail.com <ma...@gmail.com>
> >>>>>>>>> :
> >>>>>>>>>
> >>>>>>>>> What's the plan for 3.1.3 release then?
> >>>>>>>>>
> >>>>>>>>> Le sam. 24 avr. 2021 à 11:38, Mark Struberg
> >>>> <struberg@yahoo.de.invalid <ma...@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ò <
> >>>>>>>>>> ilgrosso@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/
>
>
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <rm...@gmail.com>:
>
> Le dim. 25 avr. 2021 à 13:47, Mark Struberg <struberg@yahoo.de.invalid <ma...@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 <rmannibucau@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 <struberg@yahoo.de.invalid
>> <ma...@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 <
>> rmannibucau@gmail.com
>>>>> :
>>>>>
>>>>> Le sam. 24 avr. 2021 à 22:08, Mark Struberg <struberg@yahoo.de.invalid
>>>> <mailto:struberg@yahoo.de.invalid <ma...@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 <
>>>> rmannibucau@gmail.com <ma...@gmail.com>
>>>>>>> :
>>>>>>>
>>>>>>> Le sam. 24 avr. 2021 à 17:13, Mark Struberg
>> <struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>
>>>>>> <mailto:struberg@yahoo.de.invalid <ma...@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 <
>>>>>> rmannibucau@gmail.com <ma...@gmail.com>
>>>>>>>>> :
>>>>>>>>>
>>>>>>>>> What's the plan for 3.1.3 release then?
>>>>>>>>>
>>>>>>>>> Le sam. 24 avr. 2021 à 11:38, Mark Struberg
>>>> <struberg@yahoo.de.invalid <ma...@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ò <
>>>>>>>>>> ilgrosso@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/
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le dim. 25 avr. 2021 à 13:47, Mark Struberg <st...@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 <rmannibucau@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 <struberg@yahoo.de.invalid
> <ma...@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 <
> rmannibucau@gmail.com
> >>> :
> >>>
> >>> Le sam. 24 avr. 2021 à 22:08, Mark Struberg <struberg@yahoo.de.invalid
> >> <mailto:struberg@yahoo.de.invalid <ma...@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 <
> >> rmannibucau@gmail.com <ma...@gmail.com>
> >>>>> :
> >>>>>
> >>>>> Le sam. 24 avr. 2021 à 17:13, Mark Struberg
> <struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>
> >>>> <mailto:struberg@yahoo.de.invalid <ma...@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 <
> >>>> rmannibucau@gmail.com <ma...@gmail.com>
> >>>>>>> :
> >>>>>>>
> >>>>>>> What's the plan for 3.1.3 release then?
> >>>>>>>
> >>>>>>> Le sam. 24 avr. 2021 à 11:38, Mark Struberg
> >> <struberg@yahoo.de.invalid <ma...@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ò <
> >>>>>>>> ilgrosso@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/
>
>
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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.
LieGrue,
strub
> Am 25.04.2021 um 13:39 schrieb Romain Manni-Bucau <rm...@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 <struberg@yahoo.de.invalid <ma...@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 <rmannibucau@gmail.com
>>> :
>>>
>>> Le sam. 24 avr. 2021 à 22:08, Mark Struberg <struberg@yahoo.de.invalid
>> <mailto:struberg@yahoo.de.invalid <ma...@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 <
>> rmannibucau@gmail.com <ma...@gmail.com>
>>>>> :
>>>>>
>>>>> Le sam. 24 avr. 2021 à 17:13, Mark Struberg <struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>
>>>> <mailto:struberg@yahoo.de.invalid <ma...@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 <
>>>> rmannibucau@gmail.com <ma...@gmail.com>
>>>>>>> :
>>>>>>>
>>>>>>> What's the plan for 3.1.3 release then?
>>>>>>>
>>>>>>> Le sam. 24 avr. 2021 à 11:38, Mark Struberg
>> <struberg@yahoo.de.invalid <ma...@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ò <
>>>>>>>> ilgrosso@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/
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Romain Manni-Bucau <rm...@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. 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> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le dim. 25 avr. 2021 à 13:14, Mark Struberg <st...@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 <rmannibucau@gmail.com
> >:
> >
> > Le sam. 24 avr. 2021 à 22:08, Mark Struberg <struberg@yahoo.de.invalid
> <ma...@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 <
> rmannibucau@gmail.com
> >>> :
> >>>
> >>> Le sam. 24 avr. 2021 à 17:13, Mark Struberg <struberg@yahoo.de.invalid
> >> <ma...@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 <
> >> rmannibucau@gmail.com
> >>>>> :
> >>>>>
> >>>>> What's the plan for 3.1.3 release then?
> >>>>>
> >>>>> Le sam. 24 avr. 2021 à 11:38, Mark Struberg
> <struberg@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ò <
> >>>>>> ilgrosso@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/
>
>
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <rm...@gmail.com>:
>
> Le sam. 24 avr. 2021 à 22:08, Mark Struberg <struberg@yahoo.de.invalid <ma...@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 <rmannibucau@gmail.com
>>> :
>>>
>>> Le sam. 24 avr. 2021 à 17:13, Mark Struberg <struberg@yahoo.de.invalid
>> <ma...@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 <
>> rmannibucau@gmail.com
>>>>> :
>>>>>
>>>>> What's the plan for 3.1.3 release then?
>>>>>
>>>>> Le sam. 24 avr. 2021 à 11:38, Mark Struberg <struberg@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ò <
>>>>>> ilgrosso@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/
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le sam. 24 avr. 2021 à 22:08, Mark Struberg <st...@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 <rmannibucau@gmail.com
> >:
> >
> > Le sam. 24 avr. 2021 à 17:13, Mark Struberg <struberg@yahoo.de.invalid
> <ma...@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 <
> rmannibucau@gmail.com
> >>> :
> >>>
> >>> What's the plan for 3.1.3 release then?
> >>>
> >>> Le sam. 24 avr. 2021 à 11:38, Mark Struberg <struberg@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ò <
> >>>> ilgrosso@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/
> >
>
>
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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.
LieGrue,
strub
> Am 24.04.2021 um 18:32 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Le sam. 24 avr. 2021 à 17:13, Mark Struberg <struberg@yahoo.de.invalid <ma...@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 <rmannibucau@gmail.com
>>> :
>>>
>>> What's the plan for 3.1.3 release then?
>>>
>>> Le sam. 24 avr. 2021 à 11:38, Mark Struberg <st...@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ò <
>>>> ilgrosso@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/>
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le sam. 24 avr. 2021 à 17:13, Mark Struberg <st...@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 <rmannibucau@gmail.com
> >:
> >
> > What's the plan for 3.1.3 release then?
> >
> > Le sam. 24 avr. 2021 à 11:38, Mark Struberg <st...@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ò <
> >> ilgrosso@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/>
> >>
>
>
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Who needs it?
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.
LieGrue,
strub
> Am 24.04.2021 um 13:16 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> What's the plan for 3.1.3 release then?
>
> Le sam. 24 avr. 2021 à 11:38, Mark Struberg <st...@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ò <
>> ilgrosso@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/>
>>
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
What's the plan for 3.1.3 release then?
Le sam. 24 avr. 2021 à 11:38, Mark Struberg <st...@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ò <
> ilgrosso@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/>
>
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
I'll move forward and update to 3.2.0-SNAPSHOT
LieGrue,
strub
> Am 19.04.2021 um 08:35 schrieb Francesco Chicchiriccò <il...@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/>
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Francesco Chicchiriccò <il...@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/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Maxim Solodovnik <so...@gmail.com>.
I would release 3.2.0 :)
from mobile (sorry for typos ;)
On Sun, Apr 18, 2021, 18:49 Romain Manni-Bucau <rm...@gmail.com>
wrote:
> I dont care much of this bundle naming (which looks like 3.1 since there is
> no real breaking change or arch for end users) but 3.1.3 is due so if it
> goes in 3.2.0 we should do a corelease of 3.1.3 with at least asm upgrade
> IMHO.
>
> Le dim. 18 avr. 2021 à 13:08, Enrico Olivelli <eo...@gmail.com> a
> écrit :
>
> > Mark,
> >
> > Il giorno dom 18 apr 2021 alle ore 12:31 Mark Struberg
> > <st...@yahoo.de.invalid> ha scritto:
> > >
> > > 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?
> >
> > It makes sense to me to call this new release 3.2.0
> >
> > just my 2 cents
> >
> > Enrico
> >
> > > Or is the change so subtle that we still continue with 3.1.x?
> > >
> > > LieGrue,
> > > strub
> >
>
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I dont care much of this bundle naming (which looks like 3.1 since there is
no real breaking change or arch for end users) but 3.1.3 is due so if it
goes in 3.2.0 we should do a corelease of 3.1.3 with at least asm upgrade
IMHO.
Le dim. 18 avr. 2021 à 13:08, Enrico Olivelli <eo...@gmail.com> a
écrit :
> Mark,
>
> Il giorno dom 18 apr 2021 alle ore 12:31 Mark Struberg
> <st...@yahoo.de.invalid> ha scritto:
> >
> > 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?
>
> It makes sense to me to call this new release 3.2.0
>
> just my 2 cents
>
> Enrico
>
> > Or is the change so subtle that we still continue with 3.1.x?
> >
> > LieGrue,
> > strub
>
Re: [DISCUSS] next up 3.1.3 or 3.2.0?
Posted by Enrico Olivelli <eo...@gmail.com>.
Mark,
Il giorno dom 18 apr 2021 alle ore 12:31 Mark Struberg
<st...@yahoo.de.invalid> ha scritto:
>
> 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?
It makes sense to me to call this new release 3.2.0
just my 2 cents
Enrico
> Or is the change so subtle that we still continue with 3.1.x?
>
> LieGrue,
> strub