Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Enforce SQLAlchemy-only database connections and Alembic-only schema changes

Offen
  • Stimmt etwas nicht?
#3,978 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 3 Tagen

@anth-volk arbeitet bereits daran.

Seit 20.10.2026.

  • #3979 von @anth-volk — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Veraltet
Tech-Stack
github-actions, postgresql, python, sqlalchemy
Bereich
backend, ci-cd, databases, testing

Rechercherichtung

Start with the existing rules registry and pytest guards, then inspect policyengine_api/data/v2/catalog/publication_staging.py to understand the two stated exceptions. Add a guard covering the specified code paths, proof fixtures, CI wiring in the existing test job, and guidance in docs/engineering/skills/alembic-migrations.md. Done means the guard rejects direct relational driver use and non-Alembic persistent schema changes, accepts only the exact exceptions, and its tests run in CI. Pull request #3979 is already open.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Problem

The Public API opens every relational database connection through SQLAlchemy today: API v1 builds its Cloud SQL engine in policyengine_api/data/orm.py (the Cloud SQL connector is passed to create_engine as creator=), and API v2 builds its SQLModel engine from a postgresql+psycopg URL in policyengine_api/data/v2/database.py. Schema changes go through the autogenerated Alembic revisions under migrations/v1 and migrations/v2.

Nothing enforces either of these. The rules registry has related rules, but none of them forbids:

  • a direct driver connection such as psycopg.connect(...), pymysql.connect(...) or sqlite3.connect(...), or use of the driver connection beneath SQLAlchemy, in application code, scripts or CI code. api.data.runtime-sql-confined only confines raw SQL to the data-access layer, and api.services.no-direct-queries only covers services;
  • a schema change outside Alembic, such as metadata.create_all(engine), Table.create(...), op.* outside migrations/, or CREATE / ALTER / DROP / TRUNCATE SQL text. api.migration.alembic-autogenerated-only is doc-only, and api.migration.alembic-v1-qualified / api.migration.alembic-v2-qualified check the revisions, not the code around them.

Both have happened before: the Stage 12 provisioning script (removed in d8bd72191) opened psycopg connections directly, and the local database bootstrap added in 6c7804100 called V1Base.metadata.create_all at runtime.

Proposed rule

Register an enforced rule, api.data.sqlalchemy-and-alembic-only: code connects to relational databases only through SQLAlchemy engines, connections and sessions, never by calling a database driver directly, and changes persistent schema only through Alembic revisions.

  • Enforce it with a pytest guard that parses non-test code (policyengine_api/, scripts/, migrations/, .github/, excluding tests and the generated revisions under migrations/*/versions/).
  • Declare the two current exceptions exactly, both in policyengine_api/data/v2/catalog/publication_staging.py:
    • COPY ... FROM STDIN through the psycopg connection beneath a SQLAlchemy Connection, because SQLAlchemy has no COPY API;
    • STAGING_METADATA.create_all for TEMPORARY tables that Postgres drops at commit, which are not persistent schema.
  • The guard should fail if either exception grows or is no longer needed.
  • Redis (policyengine_api/runtime_cache/) is a key-value cache, not a relational database, and is out of scope.
  • Add proof fixtures, CI wiring through the existing test job, and a section in docs/engineering/skills/alembic-migrations.md.
Vorherrschende Sprache
Python
Sterne
18
Forks
33
Ø Merge
2 T. 15 Std.
Gemergte PRs (30 T.)
35

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus PolicyEngine/policyengine-api

Alle Issues in PolicyEngine/policyengine-api

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.