# 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 БД, а потом пытаться связать данные внутри них

## мои сомнения
я недопонял смыслого посыла датасета comments, поэтому тот датасет - это количество комментариев одного пользователя под пост другого с деталями