diff options
| author | tilly-Q <nattilypigeonfowl@gmail.com> | 2013-07-29 16:36:06 -0400 |
|---|---|---|
| committer | tilly-Q <nattilypigeonfowl@gmail.com> | 2013-07-29 16:36:06 -0400 |
| commit | f2b2008da51ff554df1af0e5a14a73aff4d89c33 (patch) | |
| tree | 16e2d42c5b5fbf97b634c47741789556dd91cb75 /mediagoblin/tests/test_sql_migrations.py | |
| parent | 130b85f81ac297ebb769ab133c8adb1647d794a8 (diff) | |
| download | mediagoblin-f2b2008da51ff554df1af0e5a14a73aff4d89c33.tar.lz mediagoblin-f2b2008da51ff554df1af0e5a14a73aff4d89c33.tar.xz mediagoblin-f2b2008da51ff554df1af0e5a14a73aff4d89c33.zip | |
This was a very simple ticket actually. I created a list called FOUNDATIONS in
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.
Diffstat (limited to 'mediagoblin/tests/test_sql_migrations.py')
0 files changed, 0 insertions, 0 deletions