Комментарии 11
Поздравляю, вы только что изобрели велосипед SQLAlchemy!
Вообще, на алхимию я в некотором роде и ориентировался :)
Только здесь — это надстройка над джанговской ORM, а у ахлимии все — от пула соединений и до генерации запросов реализовано само в себе.
Не знаю, как живут нынешние попытки подружить Django и SQLAlchemy, но раньше все сводилось к тому, что открывалось дополнительное соединение к базе, что тоже не ах. Но самая большая проблема (для меня по крайней мере) — это то, что они в общем-то во многом похожи, но разные штуки реализовали по-разному. После джанги смотришь SQLAlchemy — и ощущение, будто читаешь на польском языке. А обратный переход и того хуже. Так что в одном проекте и то и другое — еще тот когнитивный диссонанс :)
Только здесь — это надстройка над джанговской ORM, а у ахлимии все — от пула соединений и до генерации запросов реализовано само в себе.
Не знаю, как живут нынешние попытки подружить Django и SQLAlchemy, но раньше все сводилось к тому, что открывалось дополнительное соединение к базе, что тоже не ах. Но самая большая проблема (для меня по крайней мере) — это то, что они в общем-то во многом похожи, но разные штуки реализовали по-разному. После джанги смотришь SQLAlchemy — и ощущение, будто читаешь на польском языке. А обратный переход и того хуже. Так что в одном проекте и то и другое — еще тот когнитивный диссонанс :)
Не обязательно новое, в github.com/Deepwalker/aldjemy я просто беру готовое.
И как оно, кстати, в продакшне? Можно использовать?
Ну я использовал. Судя по постоянным пул реквестам, кто-то еще использует. Но я джанго последний раз видел давно и на библиотеку честно говоря давно забил. А никого другого на горизонте не нарисовалось чтобы сплавить её к черту.
Да, отлично работает. Я вот как раз недавно портировал эту либу на джангу 1.8
В любом случае, воспользоваться алхимией — это уже задача другого рода. К примеру, если понадобились нормальные человеческие group by, или явные джойны (предположим, мы пошардили базу). Но если у вас есть кастомные поля или еще какой-то специфический код, реализованный в рамках джанговской ормки — будет дублирования кода (если конечно, нет возможности полностью его выкосить).
Описанный в статье самокат — только сахарку добавляет, никаких advanced usage. Зато это будет полезно при обычном использовании джанговской ормки и не требует дублирования кода в случае упомянутого специфического кода вроде кастомных полей.
Описанный в статье самокат — только сахарку добавляет, никаких advanced usage. Зато это будет полезно при обычном использовании джанговской ормки и не требует дублирования кода в случае упомянутого специфического кода вроде кастомных полей.
Ну никто со статьей не спорит – выглядит ничего так. Единственное меня в принципе раздражают стописят слоев перекладывания строк, включая собственно сам SQL, который уходит через сокет, и еще там парсится, а потом там планер, а потом, по окончании всей этой херни включается наконец-то вожделенное – достать уже чертовы строки из таблиц.
Но тут ведь не заканчивается бал безумия – теперь мы их пакуем и шлем в зад. Тут создается долбанная тонна объектов на каждую строку вернувшегося запроса, а может и больше если это был joinedload. А потом вся эта бодяга тупо перекладывается в dict, list, str, int и прочее, а потом приходит json сериалайзер, и наконец-то сборщик мусора может с удовольствие пожевать, и пусть весь мир подождет, ять.
Так что ну ок, S выглядит красиво, практически бесконечность. Еще одна маленькая игра со строками ничего особо в картине мира не испортит.
Но тут ведь не заканчивается бал безумия – теперь мы их пакуем и шлем в зад. Тут создается долбанная тонна объектов на каждую строку вернувшегося запроса, а может и больше если это был joinedload. А потом вся эта бодяга тупо перекладывается в dict, list, str, int и прочее, а потом приходит json сериалайзер, и наконец-то сборщик мусора может с удовольствие пожевать, и пусть весь мир подождет, ять.
Так что ну ок, S выглядит красиво, практически бесконечность. Еще одна маленькая игра со строками ничего особо в картине мира не испортит.
Проблема с таким сахаром в том, что из-за применения подобных подсластителей, в проекте появляется еще один мини-фреймворк. Только как правило недокументированный и толком непротестированный. Приходит, например, новый человек в проект, ожидает, что будет работать с обычным Django кодом, а тут какие-то непонятные конструкции, для разбирания в которых надо смотреть в код.
Овчинка выделки не стоит, по-моему.
Овчинка выделки не стоит, по-моему.
Тут, конечно, каждый выбирает сам. Кто-то тащит все пакеты подряд ради мелкой фичи, которую можно было написать самому. В результате при попытке их обновить, получает неожиданные падения, в худшем случае — dependency hell. Кто-то пишет все сам — это как правило касается крупных компаний, где каждая зависимость должна тщательно изучаться.
Я предпочитаю не ставить зависимости без большой необходимости, но обычно решает код. Если библиотека хорошо читаема и покрыта тестами — то почему бы и нет?
Но вообще статья скорее про программирование, а не про библиотеку. Я вот хотел подискутировать про выбранное апи.
Я предпочитаю не ставить зависимости без большой необходимости, но обычно решает код. Если библиотека хорошо читаема и покрыта тестами — то почему бы и нет?
Но вообще статья скорее про программирование, а не про библиотеку. Я вот хотел подискутировать про выбранное апи.
Тут нет единственно правильного ответа, конечно. Я просто много обжигался на том, что люди городят свои фреймворки поверх стандартных фреймворков, но им:
— не хватает опыта, чтобы понять, что то же самое легко делается стандартными средствами
— не хватает времени и терпения, чтобы задокументировать хотя бы минимально свои поделки
— тем более не хватает времени на тесты и поддержку (портирование под новые версии основного фреймворка хотя бы).
В итоге, в моей практике все подобные решения тихо загнивали создавая кучу проблем тем, кто приходил после автора гениальной «упрощающей жизнь» надстройки. А авторы эти почему-то не задерживаются подолгу в одной компании, и расспросить их о той ли иной недокументированной стороне их поделки уже нет возможности.
— не хватает опыта, чтобы понять, что то же самое легко делается стандартными средствами
— не хватает времени и терпения, чтобы задокументировать хотя бы минимально свои поделки
— тем более не хватает времени на тесты и поддержку (портирование под новые версии основного фреймворка хотя бы).
В итоге, в моей практике все подобные решения тихо загнивали создавая кучу проблем тем, кто приходил после автора гениальной «упрощающей жизнь» надстройки. А авторы эти почему-то не задерживаются подолгу в одной компании, и расспросить их о той ли иной недокументированной стороне их поделки уже нет возможности.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Django ORM. Добавим сахарку