Bases: object
A helper class for comparison of DB migration scripts and models.
It’s intended to be inherited by test cases in target projects. They have to provide implementations for methods used internally in the test (as we have no way to implement them here).
test_model_sync() will run migration scripts for the engine provided and then compare the given metadata to the one reflected from the database. The difference between MODELS and MIGRATION scripts will be printed and the test will fail, if the difference is not empty. The return value is really a list of actions, that should be performed in order to make the current database schema state (i.e. migration scripts) consistent with models definitions. It’s left up to developers to analyze the output and decide whether the models definitions or the migration scripts should be modified to make them consistent.
Output:
[(
'add_table',
description of the table from models
),
(
'remove_table',
description of the table from database
),
(
'add_column',
schema,
table name,
column description from models
),
(
'remove_column',
schema,
table name,
column description from database
),
(
'add_index',
description of the index from models
),
(
'remove_index',
description of the index from database
),
(
'add_constraint',
description of constraint from models
),
(
'remove_constraint,
description of constraint from database
),
(
'modify_nullable',
schema,
table name,
column name,
{
'existing_type': type of the column from database,
'existing_server_default': default value from database
},
nullable from database,
nullable from models
),
(
'modify_type',
schema,
table name,
column name,
{
'existing_nullable': database nullable,
'existing_server_default': default value from database
},
database column type,
type of the column from models
),
(
'modify_default',
schema,
table name,
column name,
{
'existing_nullable': database nullable,
'existing_type': type of the column from database
},
connection column default value,
default from models
)]
Method include_object() can be overridden to exclude some tables from comparison (e.g. migrate_repo).
alias of fk_info
Compare foreign keys between model and db table.
| Returns: | a list that contains information about:
Output: [('drop_key',
'testtbl_fk_check_fkey',
'testtbl',
fk_info(constrained_columns=(u'fk_check',),
referred_table=u'table',
referred_columns=(u'fk_check',)))]
|
|---|
DEPRECATED: this function is deprecated and will be removed from oslo.db in a few releases. Alembic autogenerate.compare_metadata() now includes foreign key comparison directly.
Compare default values between model and db table.
Return True if the defaults are different, False if not, or None to allow the default implementation to compare these defaults.
| Parameters: |
|
|---|
Return True if types are different, False if not.
Return None to allow the default implementation to compare these types.
| Parameters: |
|
|---|
Run migration scripts with the given engine instance.
This method must be implemented in subclasses and run migration scripts for a DB the given engine is connected to.
Filter changes before assert in test_models_sync().
Allow subclasses to whitelist/blacklist changes. By default, no filtering is performed, changes are returned as is.
| Parameters: | diff – a list of differences (see compare_metadata() docs for details on format) |
|---|---|
| Returns: | a list of differences |
Return the engine instance to be used when running tests.
This method must be implemented in subclasses and return an engine instance to be used when running tests.
Return the metadata instance to be used for schema comparison.
This method must be implemented in subclasses and return the metadata instance attached to the BASE model.
Return True for objects that should be compared.
| Parameters: |
|
|---|
Bases: object
Test mixin to check upgrade and downgrade ability of migration.
This is only suitable for testing of migrate migration scripts. An abstract class mixin. INIT_VERSION, REPOSITORY and migration_api attributes must be implemented in subclasses.
Auxiliary Methods:
migrate_up and migrate_down instance methods of the class can be used with auxiliary methods named _pre_upgrade_<revision_id>, _check_<revision_id>, _post_downgrade_<revision_id>. The methods intended to check applied changes for correctness of data operations. This methods should be implemented for every particular revision which you want to check with data. Implementation recommendations for _pre_upgrade_<revision_id>, _check_<revision_id>, _post_downgrade_<revision_id> implementation:
- _pre_upgrade_<revision_id>: provide a data appropriate to
- a next revision. Should be used an id of revision which going to be applied.
- _check_<revision_id>: Insert, select, delete operations
- with newly applied changes. The data provided by _pre_upgrade_<revision_id> will be used.
- _post_downgrade_<revision_id>: check for absence (inability to use) changes provided by reverted revision.
Execution order of auxiliary methods when revision is upgrading:
_pre_upgrade_### => upgrade => _check_###
Execution order of auxiliary methods when revision is downgrading:
downgrade => _post_downgrade_###
Initial version of a migration repository.
Can be different from 0, if a migrations were squashed.
| Return type: | int |
|---|
Allows basic manipulation with migration repository.
| Returns: | migrate.versioning.repository.Repository subclass. |
|---|
Migrate down to a previous version of the db.
| Parameters: |
|
|---|
Provides engine instance.
Should be the same instance as used when migrations are applied. In most cases, the engine attribute provided by the test class in a setUp method will work.
Example of implementation:
- def migrate_engine(self):
- return self.engine
| Returns: | sqlalchemy engine instance |
|---|
Migrate up to a new version of the db.
| Parameters: |
|
|---|
Provides API for upgrading, downgrading and version manipulations.
| Returns: | migrate.api or overloaded analog. |
|---|
Check if migration upgrades and downgrades successfully.
Determine the latest version script from the repo, then upgrade from 1 through to the latest, with no data in the databases. This just checks that the schema itself upgrades successfully.
walk_versions calls migrate_up and migrate_down with with_data argument to check changes with data, but these methods can be called without any extra check outside of walk_versions method.
| Parameters: |
|
|---|