Там алхимию подвезли с асинхронностью и тайп-хинтингом

с асинхронностью

там не тру асинхронность

В настоящее время sqlalchemy хороша только как query builder. Как ORM она ни о чём. Change my mind.

Как ORM она ни о чём

Для описания схемы БД вполне себе.

А что толку от этого описания? Если ты используешь ORM для описания базы, ты будешь использовать его и для выполнения запросов.

Complete support for Python asyncio for both Core and ORM. This new system leverages the greenlet context-switching library to adapt the entirety of SQLAlchemy to be usable behind a very thin asyncio front-end while operating directly against asyncio database drivers within the asyncio event loop, with no need for thread executors.

Вообще, я не до конца понимаю, как это работает. Кто объяснит, как можно без экзекьюторов обернуть синхронный питоновский код в асинхронщину? Что делает этот greenlet?

будешь использовать его и для выполнения запросов

Вместе с aiopg использовал для описания схемы, а в запросах только как expression language.

Не очень понимаю, как. Ты использовал декларативное описание базы, но потом делал запросы от него через aiopg? Если нет, то ты не использовал ORM, только Core.

Ты использовал декларативное описание базы

Да.

А что дальше? Как делал запросы?

А запросы - aiopg с SQL expression. Я так понимаю, это ты query builder называешь?

aiopg с SQL expression

Сырой SQL?

Нет, SQL Expression Language

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

Поддерживаю вопрос со стороны Java: зачем нужны всякие Ktor, Helidon, Quarkus и прочая реактивщина, если Hibernate на корню рубит весь смысл, а R2DBC и Hibernate Reactive — вообще не понятно что с поддержкой полутора БД.

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

Как-то так, насколько помню:

class User(Base):
    __tablename__ = 'user_account'

    first_name = Column(String(40), nullable=False)


await conn.execute(select([User]).where(User.first_name = 'Иван')

Но, в итоге, схема была на объектах Table.

Но, в итоге, схема была на объектах Table.

Именно. Так это и работает. У меня всё так же. А так как ты описал в своём фрагменте кода - не работает.

Только вот Table - это Core а не ORM. Что и требовалось доказать: SA Core - годнота, SA ORM - говно без задач.

SA ORM - говно без задач

А бывает разве годный ORM? Там по-моему сама идея гнилая.

Зависит от задач. Если например делать MVC веб приложение, то без ORM обойтись сложно.

Gino же есть. Ненужно в сущности. У меня и так асинхронная алхимия.

Все так называют.

Когда запросы простенькие, с ORM банально удобнее.

Программы имеют свойство незаметно усложняться

У меня в прошлом проекте вся работа с отдельными записями шла через ORM, а агрегации и подобное были написаны на SQL (именованные запросы, разложенные по файликам), было вполне удобно. Миграции тоже на нормальном постгресовом DDL были написаны, алембик с алхимией не использовались. Удобно и практично.

Как ORM она ни о чём. Change my mind.

Говно полное, даже чистые запросы приятнее фигарить

Лучше скажите вот это кто нибудь в продакшене уже юзал? - https://github.com/tortoise/tortoise-orm

API запросов как в Django => на помойку.

А тебе как нравится? Мне джанго отлично заходит, очень чисто и коротко получается. Правда я не настоящий сварщик.

Собственно в алхимии конструктор запросов неплох.

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

ORM must die!!

Программеры идут на невероятные ухищрения опускаясь в глубины ОРМ чтобы зоставить ОРМ выполнять SQL быстро вместо того чтобы написать простой запрос.

В настоящее время sqlalchemy хороша только как query builder. Как ORM она ни о чём. Change my mind

Исправляю тебя: ORM не нужно. Никакое.

При этом сам пишу объектную СУБД в памяти, бг-г.

ORM не нужно

Сильное заявление. Проверять я его конечно не буду.

Уже багфиксы приехали sqlalchemy-1.4.1-released

SQLAlchemy 1.4 establishes itself as the starting point for the SQLAlchemy 2.0 project, which will move fully to Python 3 only as well as finalize the new APIs introduced in release 1.4.0.

Учитывая текущий темп накручивания версий, к тому времени уже будет python 4, наверное

У меня в прошлом проекте вся работа с отдельными записями шла через ORM, а агрегации и подобное были написаны на SQL (именованные запросы, разложенные по файликам), было вполне удобно.

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

В настоящее время sqlalchemy хороша только как query builder

Я как-то разгребал проект с кучей таких запросов. И это так утомительно транслировать всё в SQL чтобы понять, чего хотели писатели и почему это сделано неправильно. А писатели наверняка выполняли обратную трансляцию натягивая SQL на глобус. Это как общаться через переводчика, хотя можно было нативно разговаривать.

только сложность поддержки удваивается

Каким образом?

Элементарно. Проект переходит в легаси и через n лет попадает ко мне для оптимизации запросов. Я хорошо разбираюсь в SQL и особенностях СУБД, но совершенно не знаю вашего ORM. И вот мне приходится разбираться еще и дополнительно с ним.

совершенно не знаю вашего ORM

Подай заявку на курсы повышения квалификации.

И вот мне приходится разбираться еще и дополнительно с ним.

Постоянно приходится с чем-то разбираться. Притом, что там нет никакого рокетсайенса.

А сложные запросы динамически строить без подобных тулзов сильно менее удобно.

Да даже банальный batch insert без query билдера — уже геморрой.

batch insert

Попрошу подробнее...
В моём опыте postgresql + pandas это загрузка csv через буфер. Только так приемлимая скоро ть insert'а достигается.

Не путай с bulk, batch — пачка — может состоять и из жалких десяти записей. Речь не про скорость вставки, а про удобство формирования запроса.