Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#3,978 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 3 jours

@anth-volk y travaille déjà.

Depuis le 20/10/2026.

  • #3979 par @anth-volk — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
github-actions, postgresql, python, sqlalchemy
Domaine
backend, ci-cd, databases, testing

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Python
Étoiles
18
Forks
33
Merge moyen
2 j 15 h
PR mergées (30 j)
35

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de PolicyEngine/policyengine-api

Toutes les issues de PolicyEngine/policyengine-api

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.