мда конечно

м?)

100 мб только на сам поетри

хотя образ python:3.7 весит 900 метров уже

ужас

В 2020 году бы место экономить

(((

Кстати, потенциально ничего не мешает вычищать poetry после установки зависимостей 🤷‍♂️

только если делать это за один RUN

мне кстати надо вызывать поетри инсталл второй раз после копирования исходников, чтобы алиасы на скрипты прописались

точно

Я тут смотрю всякие генераторы данных, типа mimesis и faker. Такой вопрос, если у меня есть pydantic классы, могу я использовать их как схему для генерации структурированных данных? Может что-то готовое есть? Погуглил, что-то ничего подобного не нагуглилось. В mimesis есть schema-based генерация, но там какая-то своя схема. Может такого и нет, чтобы автоматически, ведь в pydantic в основном описываются типы, а генерируются данные для конкретных сущностей, типа Person, Food, Country и т.п.

Привет!
Подскажите, пожалуйста, как можно обрабатывать ошибки от БД?
Т.е. есть эндпоинт, принимает json, например, такой

{
  "person_id": uuid,
  "group_id": uuid,
  "person_name": "blabla"
}

Я хочу знать, что person_id и group_id (внешний ключ) существуют в БД. Но выполнять 2 запроса для проверки, мне кажется неправильным. Можно было бы написать try except для каждого типа исключения (не найден person_id, отсутствует внешний ключ group_id) при сохранении полей этого json в БД. Но вопрос в том как это можно переиспользовать для других эндпоинтов. Потому что в другом потребуется проверка только  person_id, а в другом group_id. Пишу на fastapi.

{
  "person_id": uuid,
  "group_id": uuid,
  "person_name": "blabla"
}

👋 А как ты потом будешь обрабатывать эту ошибку? Возвращать пользователю? В каком виде?

Отправлю bad_request с сообщением, что не найден person_id или group_id.

Если я правильно помню, то SQLAlchemy на все ошибки подобного рода возвращает один тип исключения, это IntegrityError с разным текстом

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

Если такой сценарий частый, то я бы делал отдельные запросы на exists, они не очень дорогие, но позволят собирать полноценные ошибки

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

Сценарий частый, я тоже склоняюсь к отдельным запросам на exists.

Просто в большинстве случаев такая ошибка может случиться если:
- кто-то ручками пытается сделать какую-нибудь дичь
- клиент написан с логической ошибкой и пытается сделать какую-то дичь
- кто-то параллельно работал над этими же кусками данных и удалил person/group

Во всех случаях хорошо бы эту ошибку залогировать, отправить куда-нибудь алерт и разбираться как так вышло. А на клиент можно вернуть что-нибудь вроде "обновите страницу и попробуйте ещё раз" 😈, т.к. пользователь всё равно ничего с этой ошибкой не сможет сделать во всех случаях