Чтение и создание через SQLAlchemy 2

Каталог, который хранит добавленные комнаты

Roomly — это сервис, который помогает командам находить подходящие переговорные и договариваться о встречах без лишней суеты. Прежде чем коллеги смогут выбирать комнату, администратор должен наполнить каталог: описать каждое помещение и передать сведения о нём в хранилище. Хранилище принимает эти данные и само присваивает комнате идентификатор, под которым она будет жить в системе.

Ключевое требование к каталогу — стабильность: однажды добавленная комната никуда не исчезает и не меняется сама по себе при очередном обращении к списку. Коллеги могут запросить весь каталог сразу или попросить карточку конкретного помещения по его идентификатору. Если комнаты с таким идентификатором нет, сервис должен сообщить об этом внятно, а не возвращать пустоту или вести себя непредсказуемо.

Задача состоит в том, чтобы убедиться: сервис действительно хранит добавленные комнаты и корректно отдаёт их при последующих запросах. Добавление, чтение каталога целиком и получение отдельной карточки — в том числе несуществующей — должны работать именно так, как ожидают администратор и его коллеги.

Что уже дано

Это самостоятельный сокращённый пример SQLAlchemy с id/name/capacity, как в теории21, а не замена полного Roomly с Address/comment. В одном редакторе уже даны Base/Room, RoomIn/RoomSchema, engine, SessionLocal, init_db и get_db. Подключение и закрытие Session работают; три TODO находятся только в обработчиках POST и GET. Не заменяйте предоставленную базу глобальным словарём.

Перед видимым файлом служебная подготовка создаёт пустой временный каталог внутри рабочей папки и задаёт DATABASE_URL: str — SQLite URL собственного файла roomly.db. Используйте именно это имя; создавать путь или открывать прежние базы не нужно. Публичный переходник выполняет HTTP через TestClient, передаёт диагностические наблюдения и читает этот же файл отдельным SQLite-соединением. Данные для проверок поступают через RPC, ожидаемые ответы в переходнике отсутствуют. После проверки он закрывает свои ресурсы и удаляет только собственный временный каталог. Писать переходник, SQL-диагностику, управление файлами или тесты не требуется.

Что нужно сделать

Реализуйте POST /api/rooms через переданную SQLAlchemy Session: новое описание создаёт отдельную Room, идентификатор назначает хранилище, изменение фиксируется. Успех —201 и ровно id/name/capacity. Дополнительный id из JSON не назначает первичный ключ и не перезаписывает комнату. После ответа отдельный запрос и отдельное соединение к тому же файлу видят сохранённую строку. Явный refresh не обязателен, если возвращаемые данные корректны.

GET /api/rooms возвращает весь текущий каталог по возрастанию id; пустая таблица даёт []. GET /api/rooms/{room_id} возвращает200 и выбранную карточку, при отсутствии —404/{"detail":"Room not found"}. room_id берётся из пути, а не одноимённого query; неверный тип пути даёт стандартный422. Чтение и отказы не меняют строки.

Сохраните готовую валидацию: name — обязательная строка длиной2–50; capacity — обязательное целое1–50 по обычным правилам Pydantic. Неверное либо отсутствующее JSON-тело даёт стандартный422 с местом ошибки. Не добавляйте PUT/PATCH/DELETE, бронирования или новые поля. Имена обычных локальных переменных и способ получения корректного ответа выбираете вы.

Ввод и вывод

stdin не используется. Печатать через print в stdout ничего не нужно. После выполнения файла проверяющая система обращается к верхнеуровневому app: публичный переходник вызывает TestClient внутри процесса приложения и передаёт результат скрытой проверке. Запускать Uvicorn, сеть, клиентский скрипт или pytest не требуется.

POST /api/rooms с {"name":"Липа","capacity":4} возвращает201 и карточку с назначенным id. Следующий GET по этому id возвращает ту же карточку; GET списка включает её вместе с ранее сохранёнными комнатами.