Использование SQLAlchemy в django

Для начала вставал вопрос как избавится от django ORM, но он отпал как только столкнулся с сессиями. Поэтому было решено оставить в подключаемых приложениях только django.contrib.sessions.

*PLACEHOLDERS_PRE_2*

Был создан класс для создания сессий базы данных.

*PLACEHOLDERS_PRE_3*

Для создания таблиц решили использовать пакет sqlalchemy-migrate. Так как использовать syncdb мы не будем, через мигрейты создаем таблицу django_session и таблицу users.

*PLACEHOLDERS_PRE_4*

Общая структура приложения выглядит следующим образом.

*PLACEHOLDERS_PRE_5*

Заметим что в models у нас нет ни слова о моделях django зато есть наш класс User, в котором есть все нам необходимое для авторизации.

*PLACEHOLDERS_PRE_6*

Мы недолго спорили, где должен располагаться метод создания пользователя и пришли к выводу, что он будет статик-методом в самом классе User.

*PLACEHOLDERS_PRE_7*

Метод save сделаем комит в базу данных если произошли изменения в нашем классе, изменился ли username или password. Джанго даже не подозревает, как мы ее надули этим самым и установит поле last_login при авторизации пользователя.

Чем подобный подход хорош, мне кажется он более логичен.

— Определение таблиц располагается в файле db.py;
— Наши классы содержат строго определенные нами методы и ничего лишнего, а с таблицей он связывается через mapper;
— Нет ужасных менеджеров, которые на мой взгляд абсолютно бесполезны.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
Підписатись на автора
LinkedIn



35 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

ModelForms я так понимаю отломались. Запуск тестов тоже?

Осталось прикрутить шаблоны jinja2 и крепко подумать зачем вообще нужно было брать django

Да, моделформс надо писать для алхимии свои, конечно. К запуску тестов приходится прикручивать сетап алхимической базы, или рисовать тесты на каком-нибудь фреймворке отдельно (у нас так). Админка дохла, конечно, но она меня (и, впрочем, остальных) мало волнует.

Осталось прикрутить шаблоны jinja2 и крепко подумать зачем вообще нужно было брать django

Ну, еще нужно формы выбрать, урлы другие и да, после этого — щастье.

Для запусков и сетапа базы данных я заюзал вот такой скрипт, он работает и меня это устраивает.

from os import path
import sys

def setup_package():
sys.path.insert(0, path.join(path.dirname(__file__), 'src'))
from django.core.management import setup_environ
from tests import settings
setup_environ(settings)

from project.tools.dbsession import getconnection

session = getconnection('mysql+mysqldb://root:@localhost/')
session.execute('CREATE DATABASE db_test CHARACTER SET utf8 COLLATE utf8_general_ci')

from migrate.versioning.api import upgrade, version_control
repository = path.join(settings.PROJECT_ROOT, 'some_repository')
version_control(settings.SQLALCHEMY_ENGINE, repository)
upgrade(settings.SQLALCHEMY_ENGINE, repository)

def teardown_package():
from tests import settings

from project.tools.dbsession import getconnection

session = getconnection('mysql+mysqldb://root:@localhost/')
session.execute('DROP DATABASE db_test')

К вопросу о ModelForm я уже высказал свое мнение, от форм часто требуется только валидация, поэтому обычные forms.Form вполне подходят.

К вопросу о ModelForm я уже высказал свое мнение, от форм часто требуется только валидация, поэтому обычные forms.Form вполне подходят.

Ну, это сильно зависит от приложения. Когда форм мало — это ок, а когда приложение — одна огромная админка, то писать формы руками — это прямой путь в ад.

Фишка в двойной работе — вы второй раз будете описывать тот же состав полей и те же данные, что уже описали в модели.

С нуля я бы взял Flask — все равно вы теряете все приложения.

У меня сейчас стоит задача встроить sqlalchemy в существующее Django приложение, потому что нужны полноценные запросы — мрак :(

Интересная тема, обязательно присмотрюсь, спасибо! =)

Какой смысл использовать фреймворк если он по-умолчанию не решает поставленных задач? придумывать кучу хаков и магий? имхо, это нарушает идиому самого фреймворка.

Для начала вставал вопрос как избавится от ORM, но он отпал как только столкнулся с сессиями.

Поищите что-то более подходящее для достижения поставленных целей...

Django — одна большая идиома.

Я так понимаю, что админка тоже автоматически нивелируется? Ну или нужно дублировать каждую модель в двух лицах — на уровне Django ORM, и на уровне Алхимии, сторонние приложения все тоже сугубо с django orm работают.

Тогда уж проще нормальный компонентный фреймворк типа pyramid использовать.
Я в своё время в одном проекте взял Django, выкинул оттуда ORM штатный и заюзал MongoEngine для MongoDB. Проект закончил, но вопрос о смысле использования Django в таком виде для себя решил однозначно.

Django — одна большая идиома.

Интересно с каких пор фреймворк становится идиомой?)

Я так понимаю, что админка тоже автоматически нивелируется? Ну или нужно дублировать каждую модель в двух лицах — на уровне Django ORM, и на уровне Алхимии, сторонние приложения все тоже сугубо с django orm работают.

Да, админка джанги отпадает в этом случае сразу.

“Django focuses on automating as much as possible and adhering to the DRY principle.”

Идиома это или нет, но в вашем случае данный принцип нарушен :)

Django focuses on automating as much as possible

Именно это ее и погубит. :)

Но по факту, «Do not repeat yourself» не нарушается. Я не копирую свои участки кода.

Идиома — лингвистический термин, обозначающий выражение (оборот речи), употребляющееся как некоторое целое, не подлежащее дальнейшему разложению и обычно не допускающее внутри себя перестановки своих частей

Я думаю, аналогия «фреймворка» и «оборота речи» в данном случае понятна.

Но могу её распространить: я к тому, что Django очень сильно навязывает свои внутренние фичи, будь до ORM, к которому есть ряд претензий, будь то шаблонизатор, который не всегда гибок, будь то урл-роутинг и тд. И, по сути, является одним неделимым целым.

И когда начинаешь пытаться заменить один её элемент другим, начинаются пляски с бубном и создание франкенштейна. Начинаешь задумываться, не проще ли взять что-то другое :)

Обратное, кстати, тоже верно — каким-нибудь джанговым куском типа тех не несчастных шаблонизатора или ORM или форм не воспользуешься, они настолько тесно интегрированы друг в друга, что увы.

Но могу её распространить: я к тому, что Django очень сильно навязывает свои внутренние фичи, будь до ORM, к которому есть ряд претензий, будь то шаблонизатор, который не всегда гибок, будь то урл-роутинг и тд. И, по сути, является одним неделимым целым.

На самом деле не очень сильно она это навязывает. Достаточно написать свой мидл для авторизации и считай ты уже почти от нее независим (приходится смирится с фактом, что от орм джанго не убежать, как то таблица с sessions, или определение полей is_authenticated и is_anonymous у класса User, но в целом ничто не мешает вам сойти с джанги, и использовать с нее только те тулзы, которые вам полезны).

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

Формы, за всю мою работу с джанго реалии оказывались таковыми что приходилось использовать не ModelForm, а писать свои обычные forms.Form для одной только валидации.

Почему форма должна возвращать инстанс твоей модели? Это очень тесная связь формы и базы данных, такого я считаю не должно быть. Конечно, тут играет роль удобность, быстрота разработки, но такая удобность и быстрота часто превращается в сложность поддержки кода.

если я не ошибаюсь, то sourceforge пошел по схеме TG2 + MongoDB именно изза легкости подключения в данном фреймворке к данной бд

кстати если смотрите на легкие фреймфорки, то посмотрите на bottle.paws.de/.../dev/index.html
на проектах типа простенький бложек с искусственными нагрузками он опережает джангу на порядок (ну типа полностью синтетический тест).

на сложных неизвестно, тк никто не засветил пока такой на нем :(

Bottle страдает из-за тупого желания засунуть невпихуемое в один файл.

ммм, а чуть-чуть поподробнее?

Легко — открываете тот самый файл, и начинаете плеваться от попыток экономить строчки, от попыток вставить все в один файл, избегая разбиения — ну это же все чистое нарушение любых стандартов.

И все это ради того, чтобы гордо написать — мы сделали крутой фреймворк в одном файле в жалкие n строк! Но если честно, то pip абсолютно плевать, сколько у вас файлов, и сколько в них строк.

тото я думаю, чего мне джанга не идет после php-шных фреймворком. правда комьюнити у джанги огромное

как избавится от ORM

бредовее идеи я еще не встречал

я не уточнил от какой орм, поправил.

уточните еще зачем это вам понадобилось и добавить как было и что стало, для совсем начинающих.

для совсем начинающий подойдет то что есть =)

ну вы ж понимаете, что я не отстану?

а если я очень любопытный начинающий?

А что в django ORM не устроило и зачем от него избавлятся ?

Django ORM, как и любая другая часть Django, это вещь, порожденная синдромом NiH, и ни разу не дотягивающая до серьезных аналогов.

Тут дальше следует огромный список того, что умеет sqla и чего никогда не будет в джангорме. Потому что sqla написана для генерации SQL, а джангорм написан для создания бложиков.

А можно ради любопытства этот «список того, что умеет sqla и чего никогда не будет в джангорме» ? я например никогда sqla не использовал и пока не имел каких-либо ограничений в django-orm

Список в документации того и другого. Мне его составлять ради вашего любопытства никакого резона ;)

ха ха — так выходит ты голословно заявляешь то чего незнаешь

Толстый тролль, еще и тыкает незнакомым людям. Пошел бы уж лучше прочел что-ли доку сам, чем трольчить в интернетах.

ну докажиТЕ пожалуйста свою правоту — хотябы один пункт из ВАшего «огромного списка» sql-alchemy который победит django-orm — а то молодежь так и будет слепо верить что все что пишут в интернетах правда

Документация все чудеснейшим образом описывает. Я считаю, что чтение документации, 100% поможет молодежи. Поможет гораздо лучше, чем чтение комментов на DOU.

Те, кому я бы хотел что-то доказать, прекрасно знают, чем отличается sqla от джангорма.

Все с ВАМИ понятно — доказать не можете. так и запишем

Статья не о том, как избавиться от django orm и уж тем более не о списке возможностей sqla против django, так что не понимаю к чему этот срач? Так и подмывает вам двоим раздать по бану. ;)

Підписатись на коментарі