When a table is renamed with the ALTER TABLE statement, the schema
history record not only will reference the current table's unique id
in the "id" metadata, but will also refer to the old table name in
the "previousId" metadata field.
Change event consumer may specify if is able to consume tombstones or
not. If the it's not, don't send them. However, connector configuration
takes precence and thus cunsumer capability is taken into account only
when `tombstones.on.delete` is not explicitely configured for the
connector.
Also fix debezium server - setting notifier has to be done once embedded
config already exists, not before it.
Cuncurrent reading and modification of MySQL table can result into MySQL
JDBC driver ArrayIndexOutOfBoundsException when it tried to merge table
fields. This is result fo caching parepared statements while table
schema is modified. It seems that caching of prepared statements is
triggered by using fetch size. Use it only in test which needs this
option to work properly and which don't do any schema changes.
When date is zero and binary protocol use comperssion, date has zero
length [1]:
type to store a DATE, DATETIME and TIMESTAMP fields in the binary protocol.
to save space the packet can be compressed:
if year, month, day, hour, minutes, seconds and micro_seconds are all 0, length is 0 and no other field is sent
Allow zero-lenght date and return null if column is optional, epoch date
otherwise (this conforms to MySqlDefaultValueConverter.convertToLocalDate()).
[1] https://dev.mysql.com/doc/internals/en/binary-protocol-value.html#packet-ProtocolBinary::MYSQL_TYPE_TIME
MySQL protocol can change during connection and as a result our custom
field reader may fail. In such case fall back to JDBC to read the value.
This is workaround until proper solution, which will require bigger
refactoring, is implemented, see DBZ-5084 for more details.