mirror of
https://github.com/tiennm99/DocsGPT.git
synced 2026-10-04 14:12:58 +00:00
The backend import package is now docsgpt, the name it will carry on PyPI; application was far too generic to install into anyone's site-packages. git mv plus a mechanical rewrite of every import, dotted string and path reference: 734 Python files, the compose files, Dockerfile, workflows, docs, setup scripts, devcontainer, k8s manifests, vscode config, pytest and coverage config, .gitignore. Behaviour is unchanged. Kept for one release: - A top-level application package whose meta-path finder resolves application.x.y to the already-imported docsgpt.x.y object, so old imports and entry points (celery -A application.app.celery, uvicorn application.asgi:asgi_app) keep working with a FutureWarning. - Celery registers every application.* task name as an alias of its docsgpt.* task on start-up, so messages queued by the previous release still run. The redbeat key prefix moves to redbeat:docsgpt:v2: so schedule entries the previous release wrote are left unread instead of firing twice. The backend image builds from the repository root (docker build -f docsgpt/Dockerfile .) so it can ship the alias package; a root .dockerignore allow-lists docsgpt/ and application/ and keeps caches, local data, .env files, the sample index files and the Dockerfile out. Compose and the image workflows point at the new context.
68 lines
2.3 KiB
Python
68 lines
2.3 KiB
Python
"""Per-request connection helpers for route handlers.
|
|
|
|
Every route-handler that talks to Postgres opens a short-lived, explicit
|
|
transaction via the context managers in this module. The pattern is::
|
|
|
|
from docsgpt.storage.db.session import db_session
|
|
|
|
with db_session() as conn:
|
|
repo = PromptsRepository(conn)
|
|
prompt = repo.get(prompt_id, user_id)
|
|
|
|
Why explicit, not ``flask.g``: the lifecycle stays local to each handler,
|
|
which mirrors how the repository test fixtures already work and keeps
|
|
error handling obvious. Celery tasks and the seeder use the same helper
|
|
so there's one pattern to learn.
|
|
|
|
Two flavors:
|
|
|
|
* ``db_session()`` — opens a transaction (``engine.begin()``). Commits on
|
|
clean exit, rolls back on exception. Use for any handler that may
|
|
write.
|
|
* ``db_readonly()`` — opens a plain connection (``engine.connect()``) for
|
|
read-only paths. Avoids the commit round-trip on pure reads.
|
|
"""
|
|
|
|
from __future__ import annotations
|
|
|
|
from contextlib import contextmanager
|
|
from typing import Iterator
|
|
|
|
from sqlalchemy import Connection, text
|
|
|
|
from docsgpt.storage.db.engine import get_engine
|
|
|
|
|
|
@contextmanager
|
|
def db_session() -> Iterator[Connection]:
|
|
"""Transactional connection. Commits on success, rolls back on error."""
|
|
with get_engine().begin() as conn:
|
|
yield conn
|
|
|
|
|
|
@contextmanager
|
|
def db_readonly() -> Iterator[Connection]:
|
|
"""Read-only connection for handlers that never write.
|
|
|
|
The connection is placed into a Postgres ``READ ONLY`` transaction
|
|
before any caller statement runs, so an accidental ``INSERT`` /
|
|
``UPDATE`` / ``DELETE`` from inside the block raises
|
|
``InternalError: cannot execute ... in a read-only transaction``
|
|
instead of silently mutating data.
|
|
|
|
The transaction itself is rolled back on exit — a read-only
|
|
transaction has nothing meaningful to commit, and rolling back avoids
|
|
leaving the connection in an open-transaction state when it returns
|
|
to the pool.
|
|
"""
|
|
with get_engine().connect() as conn:
|
|
trans = conn.begin()
|
|
try:
|
|
# Must be the first statement in the txn; psycopg3 + SA both
|
|
# honor this and Postgres rejects writes for the rest of the
|
|
# transaction's lifetime.
|
|
conn.execute(text("SET TRANSACTION READ ONLY"))
|
|
yield conn
|
|
finally:
|
|
trans.rollback()
|