ну вот да, мне тоже первое в голову пришло, хотя к паттерну адаптер это слабо относится.

Декоратор в питоне тоже слабо относится к паттерну Декоратор.
Мир не идеален.

аргумент однако

всего лишь хочу алхимию прикрутить к FastAPI без сраных глобалов

А как в таком случае правильнее объединять данные, если они хранятся распределенно на разных бд?
Отдельно по каждому енджину забирать и потом объединять на уровне полученных объектов?

"правильнее" предполагает наличие альтернативных вариантов.

впрочем есть, dblink, как уже заметил Печенька если у тебя постгря.

ну и postgres_fdw в современных версиях постгреса

О, интересно.

Hi..
flask_mail на localhost работает письма отправляет и письма приходят
а на удаленном сервере в докер контейнере как бы  работает без ошибок но письма не приходят
шо может быть?

Проброс портов?!

Приветствую!

В sqlachemy в определении колонки у нас есть два параметра: default и server_default. Есть ли смысл определять оба?

У меня видение, что в большинстве случаев лучше определять только server_default. Пускай БД сама вставляет нужные значения, вдруг они будут туда поступать из какого-то другого источника, нежели нашего питонячего приложения.

А как делаете вы? Если ли какие-то случаи, когда лучше определять default вместо server_default?

Кажется, что default может быть полезен, когда в его формировании задействована бизнес-логика приложения.

А разве если дефолт константа, он сам как сервер дефолт не работает?

Или нет, хм

если default вычисляется приложением, то server_default не подойдет. в остальных случаях server_default.

например UUID

да, благодарю. Вобщем по умолчанию делаю server_default, и если понимаю что мне нужна именно бизнес логика питона, то только тогда default.

И еще вопрос. Раньше в postgresql были заморочки с enum типом. Переименовать какой-то enum тип можно было, но это были отдельные танцы. Надо было создать временный объект, потом были какие-то проблемы с транзакциями.

И в результате давно когда я с постгрисом работал, там где хотелось иметь поле типа enum, из-за этих проблем с миграциями было проще иметь text/varchar поле. Ну и отдельный констраинт навесить.

Но может быть за последнее время что-то изменилось в постгрисе, и теперь можно без всяких временных переменных переименновывать enum типы?

З.Ы. Чтобы не выпадать из тематики группы. И как с этим в alembic? Автоматом он может увидеть, что у меня в модели изменился enum?

у меня кажется 10й постгрес, миграции пишу на sql и енумы - это больно