What's wrong with Django
p1r4nh4 выступил на Kyiv.py, посвящённом десятилетию веб-фреймворка Django с докладом Why I dislike Django.
Со всем на видео согласен, только вот миграции получили недостаточную порцию ненависти.
Озвученная проблема с ними в следующем: они работают на уровне подключаемых application, а не на уровне проекта. Что вроде бы клёво для экосистемы подключаемых приложений всяких и очень неудобно для долгоиграющих проектов. Стартуем проект и "я его слепила из того, что было", подключила пятнадцать приложений и оно как-то поехало и его наверное даже можно будет обновить на следующую версию. В долгоиграющих проектах - боль.
Неозвученная проблема: как и вся остальная долбаная джанга с её model forms и прочими подобными штуками, миграции делают простые случаи автоматическими, а сложные случаи - намного более трудными, чем изначально было вообще без них. Я думаю, что это вообще их такой архитектурный девиз.
Когда у тебя просто добавилось или удалилось какое-то поле, пишешь manage.py <создать автоматическую миграцию> и она создаётся, её применяешь и типа зашибись. А когда какой-то более сложный случай, то нужно хорошо понимать, что происходит и на уровне SQL, и с джанго-моделями. Курить развесистые доки джанги, чтоб выкупить, что конкретно ей надо сказать, чтоб она всё сделала верно.
И многое всё равно сделать на этом уровне нельзя, и нужно падать на уровень сырого SQL и фигачить вручную. У меня нет никаких предубеждений против сырого SQL, но из-за того, что простые случаи все были автоматизированы, у людей нет ни малейшего понятия, как эта срань внутри работает и они вообще тупо в адской панике.
Если бы с самого начала всё было на сыром SQL, они могли бы постепенно осваивать это дело. Сперва написать простую миграцию ALTER TABLE shmable ADD COLUMN shmolumn varchar; добавить какой-нибудь индекс или constraint, и в результате - быть готовым к какой-то более сложной комбинации.
А с джангой - написал manage.py automigrate раз, другой, а потом - бац! Нужно раздупляться и с SQL, и с доками джанги, заставлять всё это одно с другим работать, альтеры какие-то, которые человек первый раз в жизни видит.
Спрашивается в задачнике - какого чёрта было экономить пять минут на простых альтерах вначале, чтоб теперь человек охренел и потратил три дня вместо четырёх часов?
А с какой-то там следующей версии типа 1.9 миграции ещё и обязательными становятся, вообще прекрасно :(
из фб
Со всем на видео согласен, только вот миграции получили недостаточную порцию ненависти.
Озвученная проблема с ними в следующем: они работают на уровне подключаемых application, а не на уровне проекта. Что вроде бы клёво для экосистемы подключаемых приложений всяких и очень неудобно для долгоиграющих проектов. Стартуем проект и "я его слепила из того, что было", подключила пятнадцать приложений и оно как-то поехало и его наверное даже можно будет обновить на следующую версию. В долгоиграющих проектах - боль.
Неозвученная проблема: как и вся остальная долбаная джанга с её model forms и прочими подобными штуками, миграции делают простые случаи автоматическими, а сложные случаи - намного более трудными, чем изначально было вообще без них. Я думаю, что это вообще их такой архитектурный девиз.
Когда у тебя просто добавилось или удалилось какое-то поле, пишешь manage.py <создать автоматическую миграцию> и она создаётся, её применяешь и типа зашибись. А когда какой-то более сложный случай, то нужно хорошо понимать, что происходит и на уровне SQL, и с джанго-моделями. Курить развесистые доки джанги, чтоб выкупить, что конкретно ей надо сказать, чтоб она всё сделала верно.
И многое всё равно сделать на этом уровне нельзя, и нужно падать на уровень сырого SQL и фигачить вручную. У меня нет никаких предубеждений против сырого SQL, но из-за того, что простые случаи все были автоматизированы, у людей нет ни малейшего понятия, как эта срань внутри работает и они вообще тупо в адской панике.
Если бы с самого начала всё было на сыром SQL, они могли бы постепенно осваивать это дело. Сперва написать простую миграцию ALTER TABLE shmable ADD COLUMN shmolumn varchar; добавить какой-нибудь индекс или constraint, и в результате - быть готовым к какой-то более сложной комбинации.
А с джангой - написал manage.py automigrate раз, другой, а потом - бац! Нужно раздупляться и с SQL, и с доками джанги, заставлять всё это одно с другим работать, альтеры какие-то, которые человек первый раз в жизни видит.
Спрашивается в задачнике - какого чёрта было экономить пять минут на простых альтерах вначале, чтоб теперь человек охренел и потратил три дня вместо четырёх часов?
А с какой-то там следующей версии типа 1.9 миграции ещё и обязательными становятся, вообще прекрасно :(
из фб