У нас есть приложение Django, которое ранее использовало только Postgres в качестве своей базы данных. Теперь клиент хотел бы использовать приложение с MS SQL -Server.
Ранее разработчик добавил уникальное ограничение для текстового поля. Это небольшая таблица, поэтому индекс ничего не перегружает, и, конечно, Postgres считает, что это нормально, поэтому тестирование не выявило никаких проблем. У нас есть существующий выпуск (фактически несколько выпусков), который включает миграцию для добавления этого ограничения. Допустим, это называлось app / migrations / 0002_add_unique.py
. Теперь мы получаем запрос на совместимость SQL -Server. Мы добавили опцию конфигурации сайта, чтобы установщик мог указать механизм БД, а также строку подключения, чтобы вы могли выбрать MS SQL -Server вместо Postgres, но, конечно, миграция прерывается, когда он пытается создать базу данных в SQL -Server. Миграции должны выполняться в правильном порядке, поэтому SQL -Server взрывается, пытаясь добавить недопустимое ограничение, прежде чем попадет в миграцию, которая либо удаляет ограничение, либо изменяет текстовое поле на длинный varchar.
Мы решили это в текущей версии-кандидате, изменив старую миграцию 0002_add_unique.py, чтобы она не добавляла ограничение уникальности. Существует также новая миграция для приложения, которое использует raw sql, чтобы проверить, имеет ли таблица это ограничение, отбросить его, если оно существует, затем изменить поле на varchar, а затем добавить ограничение. Это работает, но кажется уродливым go назад и модифицировать миграцию 0002. Однако я не вижу в этом никакого смысла.
Вопрос в том, что лучшее, что мы собираемся сделать, или более рекомендуемый подход, более подходящий для Django.