Как выяснить ограничения внешнего ключа таблицы MySQL, используя Doctrine 1.1?

Question

Когда две модели связаны друг с другом, Doctrine автоматически генерирует ограничения внешнего ключа в базе данных MySQL. Поведение по умолчанию для onDelete и onUpdate RESTRICT, но также может быть установлено в SET NULL или CASCADE.

Теперь я хочу создать diff миграции из существующей базы данных по сравнению с файлом YAML. Для этого я использую функцию Doctrine::generateModelsFromDB(). Я использую перегруженный versoin Doctrine_Migration_Diff, чтобы выполнить для меня разностную работу, которая заботится о несоответствующих именах классов, длинах полей MySQL и т. Д. Это все делает хорошо, но есть проблема с этими ограничениями внешнего ключа.

Когда я создаю классы PHP из базы данных MySQL, кажется, что Doctrine не устанавливает для 'onDelete' и 'onUpdate' соответствующие значения. Когда я затем пытаюсь сопоставить эти классы PHP с классами, для которых действительно установлены «onDelete» и / или «onUpdate», Doctrine пытается добавить новый внешний ключ, который уже существует, и MySQL завершается неудачей.

Я временно обошел эту ошибку, вручную игнорируя все измененные внешние ключи в моем перегруженном Doctrine_Migration_Diff, но это действительно не решение.

Что я хочу: если Doctrine считает, что необходимо добавить новый внешний ключ, есть вероятность, что он уже существует, и для чего настроено его поведение onDelete и onUpdate. Как я могу это проверить, если у меня есть имя локального поля и имя внешнего поля?

P.S. Если кто-то уверен, что это было исправлено в Doctrine 1.2 (в чем я сомневаюсь), пожалуйста, не советуйте мне обновляться. У меня есть конкретные причины для работы с 1.1 в этом случае, но это другая история. Я бы предпочел указать направление изменения кода при наличии этого исправления, что может стать шагом ближе к обходному пути.

Answer 1

Чтобы ответить на мой собственный вопрос: я довольно долго изучал исходный код Doctrine и обнаружил, что импортер MySQL не имеет функциональных возможностей для этого.

Другими словами, это невозможно безРасширяя Учение самостоятельно.

Answer 2

Ну, у меня никогда не было этой проблемы.Но я обычно использую Doctrine с Symfony, и они, возможно, настроили инструменты миграции, не привязывая их к интерфейсу CLI Symfony.

Если бы я был вами, я бы сгенерировал новую schmea из БД, а затем сгенерировал миграциюобновленная схема (сравнивает схему с моделями, я думаю).Затем выполните повторное рендеринг моих моделей.

Однако я рекомендую сделать схему достоверной.Если вам нужно использовать устаревшую БД, то при запуске создайте схему из БД.Затем все изменения БД после этого внесите в схему, а затем перенесите, используя schmea / models.