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/
