Начинающие программисты зачастую ведут свою разработку не закладывая на будущее, что созданный проект будет использоваться в продакшне, и оттого не ставят своей целью отладить все его части. Так появляется код, в котором не настроены миграции, да и собственно моделей сущностей в коде нет, вместо них чистые SQL-запросы. Когда оказывается, что проект все же требует дальнейшей поддержки и развития возникает задача провести рефакторинг, а именно прописать модели и настроить проведение миграций, чтобы было удобнее добавлять и изменять поля сущностей в базе данных. В одном из таких проектов, который попал ко мне я решил использовать orator-orm, потому что, почитав ее документацию, эта ORM очень заманчиво подходила как быстрое решение для вышеописанной проблемы.
Схема использования проста:
- создается модель без описания каких бы то ни было полей, а только указывается имя таблицы, соответствующее сущности в БД.
- выполняется команда создания миграции, которая подтягивает из указанной таблицы названия полей и их типы и на их основе формируется питоновский файл для моделей
- далее можно создавать новые шаблоны миграций, куда прописываются новые поля, которые должны быть созданы, либо изменение/удаление.
Таким образом описание полей переносится из файла с моделями в каталог с файлами миграций и программисту уже нельзя взглянуть на модель и понять что она из себя представляет. Это плата за скорость создания миграций. В ходе использования ORM я обнаружил и другие минусы:
- нельзя наследоваться от кверисета при запросах delete и select, например, как это сделано в Django ORM;
- неочевидный метод get у селекта, который возвращает множество объектов вместо одного;
- метод first_or_create возвращает только объект, а не ожидаемую вторую переменную со значением получен объект или создан;
- декоратор belongs_to съедает форинкей поле;
- ORM требует всегда наличия идентификатора в таблицах;
- сложность с left outer join;
В целом выясняется, что эта ORM (версия 0.9) пока сыра и требуется немало изменений, чтобы сделать ее удобнее.