extensible autogen compare #306
Closed
Milestone
Comments
Michael Bayer (@zzzeek) wrote:
→ c5be317 |
Changes by Michael Bayer (@zzzeek):
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Migrated issue, originally created by Michael Bayer (@zzzeek)
replace the whole "diffs" list with a system that generates the Ops directives directly from autogenerate.render. Instead of
diffs.append(('add_index', Index))
it'sops.append(AddIndex.from_index(index))
. This removes the need for compose._produce_adddrop_command, compose._produce_modify_command, and compose._produce_command.the production of the list here will now do the "compose" in place; e.g. when we do compare_tables, we first produce an ops.ModifyTableOps, and pass that into sub-operations. This removes the need for compose._group_diffs_by_table..
Most ops will now have a reverse() function. CreateIndex reverses to DropIndex and vice versa, UpgradeOps reverses to
DowngradeOps(ops=list(reversed([o.reverse() for o in upgrade.ops])))
and vice versa, etc. This removes the need for compose._to_updown_op and related functions.with #3, we now just produce an UpgradeOps from alembic.compare, and the DowngradeOps is just upgrade_ops.reverse(). this removes the need for compose._to_migration_script.
the use case of the legacy "diffs" being needed is now met by a new method on each Ops object,
to_simple_diff()
, which produces that old tuple; the autogenerate.api.compare_metadata function will call upon produce_migrations, then run through the whole UpgradeOps list, flattening it and runningto_simple_diff()
. This is also how user-defined operations can participate in the old-school "diffs" API. The current test suite that runs compare_metadata can continue to use this function.the compare system needs to break into dispatch hooks, e.g. util.Dispatch, but a new list-version util.ListDispatch. Targets will be specific to UpgradeOps representing schema-wide changes, and ModifyTableOps for table-specific changes, which will invoke in the same place that foreign key / unique constraints and indexes are run, e.g. in between column adds and drops. We can also add AlterColumnOp as a dispatch target, where column-specific migrates can be detected, the current example being MySQL autoincrement. Each hook will have a different callable style that is specific to the type of diff we are doing.
the "include object" hook needs to be passed to the dispatchers we are doing in #6 as well in some way that isn't going to break; need to decide if the user-defined comparison function calls upon include object itself or if this is done in some automated way.
as always, the internal system needs to use these hooks. so the AlterColumnOp dispatcher itself is consulted within the dispatch for ModifyTableOps, the ModifyTableOps dispatcher itself is consulted within the dispatch for UpgradeOps.
The text was updated successfully, but these errors were encountered: