Comments 18
Django 3.0 будет асинхронным
НО ЗАЧЕМ?
Тут не «можем потерять пользователей», а «практически вероятна смерть проекта».
Всё вширь и вширь. Ни ORM, ни шаблонизатор по-прежнему не дотягивают до аналогичных решений в проектах Flask (Jinja2, SQLAlchemy). Кстати, асинхронные проекты flask'у подобные уже давно прекрасно существуют и развиваются.
SQLAlchemy — поддержывает максимум фич базы даных
Django ORM — максимально удобно поддежрывает основые фичы баз даных
Посмотрите на Django REST Framework. Не думаю, что его реально сделать на SQLAlchemy
У нас на проекте использовали обе ORM через aldjemy
При чем тут фичи баз данных, если как орм алхимия более гибкая и функциональная? В т.ч. построитель запросов. И это факт. Да, джанговская орм простая и удобная и с этим никто не спорит. Почему я должен Django REST Framework делать на SQLAlchemy? O_o И это как-то характеризует SQLAlchemy? А минус в карму за то, что кто-то со мной просто не согласен?
При чем тут фичи баз данных, если как орм алхимия более гибкая и функциональная?
Как в SQLAlchemy сделать:
- аналог менеджеров (удобно иметь
Model.objectsдля не удаленных записей иModel.all_objectsдля всех. Либо добавить функциюModel.objects.filtrate_for_userкоторая фильтрирует данные доступные для пользователя) - сделать авто join (что бы, например, сделать
queryset.filter(some__nested__field=2)на основе queryparams) - селектнуть только некоторые поля и затем обратится к свойству объекта (
User.objects.field('birthday').get().ageгдеageэтоpropertyкласаUser) - автоматически сделать запрос только в случаи необходимости:
user = User(
id=jwt_token_payload['user_id'],
username=jwt_token_payload['username']
)
print(user.id)
if some_case:
print(user.first_name) # дополнительный запросА в Django ORM невозможно сделать select ... from <subquery> что очень полезно в сложных агрегациях
Почему я должен Django REST Framework делать на SQLAlchemy?
Это просто пример в каких случиях Django ORM более удобна
Я также начал с SQLAlchemy и плохо относился к Django ORM до того как поработал с Django REST Framework.
А минус в карму за то, что кто-то со мной просто не согласен?
У меня нету таких прав.
Django выстрела в свое время за счет технически взвешенных решений и грамотной работы с комьюнити. В последнее время оно все больше напоминает фичеризм и заигрывание с инвесторами.
"Сделаем джангу асинхронной" как лозунг звучит интригующе. Это как повернуть реки вспять. Только для этого надо принять волевое решение и переписать все с нуля.
Имплементация asgiref, упомянутого в статье, больше похожа на попытку приделать груду костылей вопреки, а не благодаря выбранным архитектурным решениям. Это тупиковый путь.
Полумерами разработчики с поддержкой и старой и новой логики можно подписаться на пару лед ада для себя и пользователей.
Что ж, на днях вышла первая альфа и вроде как случился feature freeze, а от асинхронщины успели завезти только поддержку ASGI. Async views всё ещё в процессе, да и над способом реализации асинхронных class-based views ещё думают.
А я надеялся, что Джангу уже не придется учить… FastAPI + VueJS до недавнего времени был всем, что я мог хотеть. Но теперь возникает другой вопрос — не является ли Джанга лютым оверхедом если я пеку простые микросайты?
В master-ветку добавили асинхронные представления.
Django 3.0 будет асинхронным