Python-сообщество

o7412369815963
это имхо, построено по отзывам других людей.

В том числе.
Некоторые вещи даже прямо прописаны в документации самими разработчиками.
Например, ОРМ не рекомендуется использовать в серьезных проектах.

Миграция - гм…

Что это значит?

Это значит, что подход при работе с изменениями структуры БД оставляет желать лучшего.
Есть “магические” приложения-помощники, но, как часто с магией бывает :), при чуть более сложных изменениях магия исчезает и непонятно как решать задачу.

Всё равно не понимаю, что вы имеет в виду. Что значит магические? Есть south он достаточно хорошо справляется со своей задачей. В нём можно делать миграции схемы и данных в автоматическом либо ручном режиме.

Магические с точки зрения человека, использующего эти приложения.
Как обычно, в 80% случаев все работает, а когда наступают оставшиеся 20% быстро разобраться с ними может лишь разработчик приложения.
Остальные не знают, нужно копаться в коде, отлаживать.
Причина?
Я считаю,- малое количество документированных use-case, которые даже не покрывают обычные случаи.
Вот, например, ваши слова:

проблему легко проверять просто смотря в базу и наблюдая создалась ли таблица south_migrationhistory или нет

Согласитесь, если если новый инструмент требует вернуться к ранее используемому инструменту, значит что-то с новым не так.

Я не понимаю, о чём вы говорите. Что значит новый инструмент? South не заменяет Django ORM, а дополняет её, позволяя автоматически или вручную создавать миграции и выполнять их.

Я лично использую south несколько лет, очень доволен, в код заглядывал пару раз за это время. Возможно, у нас различаются профили использования этого инструмента.

lorien
Я лично использую south несколько лет, очень доволен

Дык на безрыбье и рак рыба.

Давайте вернемся к началу обсуждения.
Вот есть Джанго ОРМ.
Он призван заменить стандартную парадигму работы с БД, облегчить и ускорить работу разработчика - вот она магия.
Так ли это? Все ли задачи, которые для разработчика выполняет СУБД, выполняет ОРМ.
Нет.

Сначала оказалось (конечно, это не было сюрпризом, просто подчеркиваю), что миграция от одной схемы БД к другой работает совсем не в стиле ОРМ.
Появляются помощники миграции.
Решают ли они этот вопрос?
Тоже нет и вы не один, кто с этим сталкивался и вынужден был возвращаться к прежним инструментам из комплекта СУБД. Интернет пестрит вопросами на эту тему.
Значит, корень проблемы совсем не в подготовленности разработчика, а в самом инструменте.

Я коснулся только узкой проблемы.
А есть ведь еще проблема сложных запросов, оптимизации…

Хорошая архитектура отличается от посредственной тем, как она описана в расчете на изменение внешних условий.

На примере Джанго это могло бы выглядеть так.
В документации прописываю весь перечень операций с Джанго.
По каждой операции привожу текущее состояние инструментов, модулей, которые ее выполняют и, если необходимо, план развития, изменения.
Если на текущий момент нет инструмента для миграции, я так и пишу: есть такая штука как миграция. Готового инструмента еще нет. Он запланирован (или не запланирован) и стоит в списке задач - вот ссылка на список.
У вас есть 2 варианта: сделать самим (если кто-то уже делает, вот ссылки на репозитории) или подождать.
Если у меня есть требования к таким инструментам, я их указываю.
Если требования еще не сформулированы, так и пишу: для инструмента миграции в такие-то сроки будут написаны требования для правильной их интеграции в архитектуру системы.
Подождите, люди добрые, кто собрался писать такой инструмент сам.

Вот признак хорошей архитектуры: задачи известны заранее, в системе есть четкое место, куда будут встроены инструменты для их решения.
Отсутствие инструмента на текущем этапе развития системы не делает архитектуру плохой, в отличие от отсутствия описания инструмента.

Именно так PEP делают и потом внедряют.

К сожалению, не могу поддержать дискуссию по поводу дизайна django ORM и south т.к. мне нечего сказать. Меня django orm и south удовлетворяют. Если не будет удовлетворять в силцу специфики задачи, просто найду другое решение.

А что пирамида, как там решён вопрос миграций?

lorien
К сожалению, не могу поддержать дискуссию по поводу дизайна django ORM и south т.к. мне нечего сказать.

Жаль, мне интересно ваше мнение.

lorien
А что пирамида, как там решён вопрос миграций?

Пирамидчане рекомендуют использовать SQLAlchemy, с которым в коробке раньше шел sqlalchemy-migrate, а сейчас Alembic.
Хотя, он тоже далек от идеала, но хотя бы четко расписаны возможности, невозможности (причем, даже степень невозможности).
Плюс версионность поддерживает работу с бранчами - весьма полезно для командной работы.

Я несколько раз пытался использовать алхимию в своих проектах (и каждый раз возвращался к django orm), однажды я даже дошёл до того, чтобы делать миграции алембиком. Алембик мне менее удобных показался, чем south, он не мог автоматически делать простые миграции. Я уже не помню подробностей, но помню, вокруг каждой миграции приходилось плясать некоторое время, чтобы её написать. Ну и в целом sqlalchemy я так и не осилил, для уровня сложности моих задач целиком и полностью подходит django orm, причём я не говорю только о веб-сайтах, о системах парсинга данных из сети тоже говорю.