DECIMAL with server-side prepared
statement ignores scale if zero-padding is needed (this ends up
being due to conversion to
by server, which when converted to a string to parse into
BigDecimal, loses all “padding”
when building DBMD queries.
Use our own implementation of buffered input streams to get
around blocking behavior of
java.io.BufferedInputStream. Disable this
returns incorrect values for multi-byte charsets.
Field.isOpaqueBinary() to detect
CHAR( to support fixed-length binary fields for
n) CHARACTER SET
Failing to connect to the server when one of the addresses for
the given host name is IPV6 (which the server does not yet bind
on). The driver now loops through all IP
addresses for a given host, and stops on the first one that
Removed unwanted new
ResultSet constructor due to bad merge
(caused a new object instance that was never used for every
result set created). Found while profiling for Bug#6359.
short-lived objects unnecessarily.
Use null-safe-equals for key comparisons in updatable result sets. (Bug#6225)
Fixed too-early creation of
EscapeProcessor.escapeSQL(), also return
String when escaping not needed (to avoid
unnecessary object allocations). Found while profiling for Bug#6359.
UNSIGNED BIGINT unpacked incorrectly from
server-side prepared statement result sets.
Added experimental configuration property
dontUnpackBinaryResults, which delays
unpacking binary result set values until they're asked for, and
only creates object instances for nonnumerical values (it is set
false by default). For some usecase/jvm
combinations, this is friendlier on the garbage collector.
Don't throw exceptions for
Inefficient detection of pre-existing string instances in
Use a per-session
Calendar instance by
default when decoding dates from
ServerPreparedStatements (set to old, less
performant behavior by setting property
Fixed batched updates with server prepared statements weren't looking if the types had changed for a given batched set of parameters compared to the previous set, causing the server to return the error “Wrong arguments to mysql_stmt_execute()”. (Bug#5235)
Handle case when string representation of timestamp contains
.” with no numbers
Server-side prepared statements did not honor
zeroDateTimeBehavior property, and would
cause class-cast exceptions when using
ResultSet.getObject(), as the all-zero string
was always returned.
Fix comparisons made between string constants and dynamic
strings that are converted with either
toLowerCase() to use
Locale.ENGLISH, as some locales
“override” case rules for English. Also use
StringUtils.indexOfIgnoreCase() instead of
.toUpperCase().indexOf(), avoids creating a
very short-lived transient