Grails 2.4.4 DataSource create-drop не может удалить все таблицы с FK

Используя Grails 2.4.4, я перенес свои классы предметной области из версии 2.2.0.

Есть проблема, с которой я столкнулся в конфигурации DataSource «создать-удалить», используя MySQL в качестве источника данных.

Всякий раз, когда я запускаю команду grails stop-app, из 35 таблиц в схеме остается 22 таблицы.

После включения режима отладки для классов Hibernate и в конце процесса остановки приложения он генерировал drop table if exists <tablename> для всех 35 таблиц, но в журналах не было ошибок/подтверждений о том, удалось ли удалить таблицу или нет.

Оставшиеся таблицы имеют ассоциации FK, и их необходимо удалить в определенном порядке. С той же структурой класса домена у меня никогда не было этой проблемы с более ранней (2.2.0) версией Grails.

Прямо сейчас я каждый раз перед запуском приложения создаю вручную, так как это вызывает проблемы с данными BootStrap.

Любой указатель на отладку этой проблемы или вариант использования, когда это может произойти, будут оценены.


person v1p    schedule 19.01.2015    source источник
comment
У вас должны быть операторы DDL, удаляющие внешние ключи перед удалением таблиц, например. alter table tablename drop foreign key FK_hrogx8ddq6cptuh5ru8uycn6s. Запустите grails schema-export и посмотрите на target/ddl.sql, чтобы увидеть SQL, который генерирует Hibernate.   -  person Burt Beckwith    schedule 19.01.2015
comment
Спасибо @BurtBeckwith. Я запустил grails schema-export и сгенерировал файл, а начальные 35 строк — drop table if exists <tablename> . В файле нет alter table tablename drop foreign key <FK>.   -  person v1p    schedule 19.01.2015
comment
Вот как устроен файл: сначала drop table if exists <tablename>, потом create table <tablename>, потом alter table add UK constraints и создание индексов, в последнем alter table add FK constrains   -  person v1p    schedule 19.01.2015
comment
Мой плохой, мне очень жаль, я лучше перестану работать допоздна. Я поместил этот файл ImprovedMySQLDialect, чтобы избавиться от этого несколько дней назад. так что я по незнанию запретил падение FK. Поэтому, чтобы избавиться от этой другой проблемы, мне нужно реализовать лучшее решение. рассмотрим переопределение метода dropConstraints(). Спасибо @BurtBeckwith за то, что указал мне правильное направление.   -  person v1p    schedule 19.01.2015


Ответы (1)


В моем случае установка FK-проверок на 0 для MySQL (v5.5.25) решила эту проблему, хотя я не совсем уверен, должен ли я вообще SET FOREIGN_KEY_CHECKS=0.

Если у кого-то есть лучшее решение, пожалуйста, поделитесь.

ИЗМЕНИТЬ

Проблема возникла из-за этого. Усвоенный урок: нельзя бездумно копировать и вставлять случайный код ~:-/

ОТВЕТ

Спасибо Берт.

Если БД ведет себя хаотично по отношению к операциям ddl. Всегда проверяйте ddl.sql, сгенерированный grails schema-report, который в идеале должен иметь следующую структуру

alter table <Table> drop constraint <Constraint>
...

drop table if exists <Table>
...

create table <Table>(...)
...

create index <Index> ...   --(if any)
...

alter table <Table> add constraint <Constraint>
....
person v1p    schedule 19.01.2015
comment
где вы установили этот SET FOREIGN_KEY_CHECKS=0? Не могли бы вы уточнить? - person Chetan; 09.02.2015
comment
@Chetan: SET FOREIGN_KEY_CHECKS=0 был установлен вручную в сеансе консоли mysql, где я вручную удалял все таблицы. - person v1p; 10.02.2015
comment
но реальная проблема заключалась в пользовательском классе MySQL5InnoDBDialect, который я написал, с переопределенным методом public boolean dropConstraints(), возвращающим false - person v1p; 10.02.2015