You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The internal system for Alembic operations has been reworked to now
build upon an extensible system of operation objects. New operations
can be added to the op. namespace, including that they are
available in custom autogenerate schemes. fixes operations as objects #302
The internal system for autogenerate been reworked to build upon
the extensible system of operation objects present in operations as objects #302.
A new customization hook process_revision_directives is added
to allow manipulation of the autogen stream. Fixes extensible revision / autogenerate strategies #301
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
The text was updated successfully, but these errors were encountered: