In Debezium 0.9, if the timezone of the JVM running Debezium had an
earlier offset than the timezone of the MySQL server, any values of type
DATE read by the snapshot reader would be incorrectly shifted backwards
by one day. This was the result of a known bug/deficiency in MySQL's
JDBC connector [0].
This bug was inadvertently fixed in Debezium 0.10 by #913, which
bypassed the JDBC date retrieval logic to support zero dates, thus also
avoiding the inappropriate timezone shifting logic. However, since the
fix was inadvertent, there was no test to protect against regression.
This commit adds such a regression test. Since the MySQL server used in
tests uses timezone GMT-11, we just need to run a SnapshotReader in
timezone GMT-12 and verify that the dates are computed correctly. This
test fails if added to Debezium 0.9, but passes now thanks to #913.
Humorously, it is likely someone would have noticed this bug long ago
had the test MySQL server used any other timezone; for example, if the
MySQL server used EST as its timezone, anyone running the tests from the
International Date Line to Chicago would have seen the failure. Bt with
GMT-11 there is only one timezone with a smaller offset, GMT-12, which
is only used by tiny outlying islands of the US.
[0]: https://bugs.mysql.com/bug.php?id=91112
This commit adjusts the JIRA references such that we introduced a new jira-url
Ascidoc attribute which now points to issues.redhat.com rather than using full
url references across all pages to the same host.
- kafka topics names are case sensitive. We should not perform
a toLowerCase on the topic name. It can cause some issue if
topic name have a upper case
When running:
```
DELETE FROM customers WHERE id=1004;
```
I get back:
```
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`inventory`.`addresses`, CONSTRAINT `addresses_ibfk_1` FOREIGN KEY (`customer_id`) REFERENCES `customers` (`id`))
```
So I added some instructions on deleting this entry first before continuing.