python_dev

Запуск

cp .env.example .env docker compose up -d

миграции БД

cp .env.example .env cd alembic/db1 && alembic revision --autogenerate && alembic upgrade head cd alembic/db2 && alembic revision --autogenerate && alembic upgrade head

режим разработки

cp .env.example .env rye sync granian src/app.py --reload

структура проекта

📦python_dev_farpost ┣ 📂alembic ┃ ┣ 📂db1 - вспомогательные инструменты alembic для миграций первой БД ┃ ┗ 📂db2 - вспомогательные инструменты alembic для миграций второй БД ┣ 📂database ┃ ┣ 📂dumps - дампы БД ┃ ┗ 📜....sh - скрипт, для автоматизации создания и импорта дампов в multiDB ┣ 📂src ┃ ┣ 📂adapters ┃ ┃ ┗ 📂database - модели sqlAlchemy и инструменты для подключения к БД ┃ ┣ 📂api - эндпоинты fastapi + формирование датасета (не делил ввиду отстутствия необходимости) ┃ ┣ 📂schemas - схемы для обработки входных и выходных данных (в тч валидации данных для БД) ┃ ┣ 📜app.py - приложение для запуска ┃ ┣ 📜settings.py - валидация настроек из .env, которые в дальнейшем удобно брать ┣ 📜.env.example - ┣ 📜.gitignore ┣ 📜compose.yaml ┣ 📜Dockerfile ┣ 📜Makefile ┣ 📜pyproject.toml - данные проекта для запуска rye ┣ 📜README.md ┣ 📜requirements-dev.lock ┗ 📜requirements.lock

что не по ТЗ

• мне не очень понравилось, что space_type и event_type сделаны через отдельные таблицы

  • потому что работать с этой таблицей будет бэкенд, и у нас есть различные API хэндлеры, которым, чтобы создать запись в БД нужно сходить на дочерние таблицы, найти нужный тип (например event_type - login), взять от него id, прийти назад и создать запись с нужным id, при этом это ещё будет не надёжным (кто-то удалит тип, поменяет название, всё поляжет) + а зачем нам отдельная таблица? (я в том смысле, что над этими типа у нас есть все операции круд, но без изменения кода бэкенда - это либо бесполезно, либо опасно)
  • я заменил на более удобные Enum

• датасет comments

  • так как информации о связи постов комментариев не было - я создал таблицу Comment
  • было упоминание в таблице логов, которую можно было дополнить столбцом, но мне кажется это не очень хорошим решением было сначала разделять на 2 БД, а потом пытаться связать данные внутри них