The goal is to get things to the point where Alembic can run on its own
for new databases and initialize the whole database on its own. There
are risks to not doing so, see #5413 for details.
There's a lot more here that could removed or cleaned up once
sqlalchemy-migrate is *completely* removed in the future.
* mediagoblin/db/migration_tools.py (MigrationManager.foundations):
Removed attribute.
(MigrationManager.populate_table_foundations): Removed method.
(MigrationManager.init_or_migrate): Removed call to deprecated method.
(populate_table_foundations): New function, refactored from former
MigrationManager method of same name.
* mediagoblin/gmg_commands/dbupdate.py: Import populate_table_foundations.
(DatabaseData.foundations): Remove attribute.
(DatabaseData.make_migration_manager): Adjust instantiation of
MigrationManager.
(gather_database_data): Move out the work of building up foundations data.
(run_foundations): New method, incorporating logic for gathering and
running foundations which was previously spread across other
functions and methods.
(run_alembic_migrations): Remove deprecated comment.
(run_dbupdate): Only run sqlalchemy migrations if we have to.
Also run run_foundations if we are setting up this database for the
first time.
(sqam_migrations_to_run): New method.
This makes use of the recently added "build_alembic_config" tool and
removes AlembicMigrationManager.
* mediagoblin/db/migration_tools.py (AlembicMigrationManager): Removed.
* mediagoblin/gmg_commands/dbupdate.py (run_alembic_migrations):
Adjusted to use recently added build_alembic_config tool.
For some reason the alembic connection wasn't seeing any tables that existed
however the existing connection works well and we shouldn't be creating a brand
new one when we have one ready to use. I've used a little bit of a hack due to our
old version of alembic.
After 0.7.5 of alembic it offers a `Config.attributes` dictionary which is designed to
allow you to pass your connection/engine/whatever to the env.py config script so you're
not required to create new ones. As we're on an older version I just create a dictionary
with the same name and use it as otherwise documented. It seems this is the suggested
fix for #5395 and it fixes#5398 too.
The database connection was being set in a alembic.ini config file, if the user
had specified postgres the "sqlite" connection URL in alembic.ini would override
that. We probably should look into this more so i've opened #5395.
Some sqlite migrations were failing due to some problems with sqlite. A
work around has been created for these however it does involve loading lots
of data into memory. If you have a large database you should consider trying
to move to postgres.
around the SQLite problems with Alter table. I added a new function to
migration_tools (replace_table) which does all the work I did in my migration of
core__users, but is now usable for other migrations.
for plugins. In this commit I changed the MigrationManager and DatabaseData ob-
jects to account for FOUNDATIONS in any plugin's (or main program's) models.py
file.
mediagoblin/db/models.py. This list holds all of the information about rows that
should be created at database initialization. Read the documentation near the
FOUNDATIONS list to understand the proper format for this list.
All of the work is done through a new method on MigrationManager in
mediagoblin/db/migrations_tools.py. This method, `populate_table_foundations`
parses the FOUNDATIONS list and creates the foundations based on the data incl-
uded. This only ever happens when the database is initialized. Migrations to
releases with new Foundations should be very easy just using the basic
database functionality.
