trader.persistence.migrations module¶
Alembic integration: stamping fresh databases, and upgrading existing ones.
Why `create_all` still exists alongside migrations. init_db builds a new database with create_all rather than by replaying every migration, because the test suite creates over a hundred throwaway databases and replaying the history for each one costs far more than it proves. The risk that buys — the two definitions drifting apart — is closed by tests/persistence/test_migrations.py, which fails if the models and the migrations disagree. That is this project’s equivalent of Django’s makemigrations –check.
A database built by create_all is stamped at head immediately, so Alembic knows its tables already exist and the next upgrade applies only genuinely new revisions.
- trader.persistence.migrations.alembic_config(database_url)[source]¶
An Alembic config pointed at database_url.
The URL is set here rather than read from alembic.ini, for the same reason env.py resolves it from Settings: one place decides where the database lives.
- Parameters:
database_url (str)
- Return type:
Config
- trader.persistence.migrations.current_revision(database_url)[source]¶
The revision database_url is stamped at, or None if unstamped.
- Parameters:
database_url (str)
- Return type:
str | None
- trader.persistence.migrations.stamp_head(database_url)[source]¶
Record database_url as being at the latest revision, creating nothing.
Used after create_all on a fresh database, and it is also how an existing database adopts Alembic. Running upgrade on either would fail on the first CREATE TABLE, because the tables are already there.
- Parameters:
database_url (str)
- Return type:
None