Description
Migrated issue, originally created by Michael Bayer (@zzzeek)
to allow extensibility:
-
primary methods in operations move to be exported from objects, extending a base Operation type, e.g.
AddTableOperation -
object-building methods in operations move to a utility object "objects" or similar, e.g. _table(), _metadata(), _unique_constraint();
-
Operation objects include a convenience op_method, which goes into operations and defines the docstring, and does the things that are inside of operations.py right now, e.g. calling upon objects.table(), etc. then calling the more fundamental version of itself on a given
"impl". E.g. under "class Operations:" we have "drop_table = DropTable.get_op_method()". -
Operation objects also integrate with autogenerate render; methods in autogen.render such as _add_index, _drop_table etc. go onto a compiler object that uses a visit pattern, given Operation objects.
-
autogenerate api -> _produce_commands will deal in these directives now. the directives are first generated from the diffs stream
-
the Operation objects also store a reference to the diff object they got from the diffs stream,
-
the Operation objects use a generic dispatcher pattern; so when Operation is invoked such that we want it to acutally do say a "drop_table", it is given a generic "impl" upon which it invokes "drop_table". The object is not stateful in terms of it "doing" anything. this is the basic visitor / dispatch pattern that will also work for the autogen render aspect.
-
extensibility is key so ensure Operation objects have an .info as well.
-
rework the modules into sub-packages where things involving the new Operation scheme is in alembic.operations, so the existing "operations" and "batch" move into there as well.
-
operations.BatchOperations subclass probably needs to stay as is for now
see also #301