Я строю образ Docker с MySQL 5.6 внутри (только для целей тестирования / CI) и создаю схему и все таблицы, а затем фиксирую контейнер докера в качестве изображения. Я намеренно переназначаю DATADIR в определенное место, чтобы держать его внутри контейнера, а не на томе.
Базовое изображение mysql/mysql-server:5.6
Я заметил это супер странное поведение:
Каждый раз, когда я запускаю контейнер и выполняю следующий запрос в первый раз:
select * from information_schema.REFERENTIAL_CONSTRAINTS;
я вижу что-то вроде:
+-----+------------------------+-----+
| ... | UNIQUE_CONSTRAINT_NAME | ... |
+-----+------------------------+-----+
| | NULL | |
| | PRIMARY | |
| | PRIMARY | |
| | PRIMARY | |
| | NULL | |
| | PRIMARY | |
| | NULL | |
Но если я снова его вызываю сразуЯ вижу
+-----+------------------------+-----+
| ... | UNIQUE_CONSTRAINT_NAME | ... |
+-----+------------------------+-----+
| | PRIMARY | |
| | PRIMARY | |
| | PRIMARY | |
| | PRIMARY | |
| | PRIMARY | |
| | PRIMARY | |
| | PRIMARY | |
Так что после первого вызова некоторые из ограничений с изначально NULL-значениями каким-то образом «инициализировались».
Код создания этих внешних ключей похож, поэтому понятия не имею, почему некоторыеиз них есть NULL, а некоторые нет.
...FOREIGN KEY (campaign) REFERENCES coupon_campaign(_id) ON DELETE CASCADE,...
Почему это может причинить вред? Я использую JOOQ и хочу создать jooq-codegen для созданного контейнера. И поскольку JOOQ использует эти системные таблицы для описания структуры данных, она дает противоречивые результаты.
Может кто-нибудь подсказать, почему это может произойти?