New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

operations as objects #302

Closed
sqlalchemy-bot opened this Issue Jun 11, 2015 · 3 comments

Comments

Projects
None yet
1 participant
@sqlalchemy-bot

sqlalchemy-bot commented Jun 11, 2015

Migrated issue, originally created by Michael Bayer (@zzzeek)

to allow extensibility:

  1. primary methods in operations move to be exported from objects, extending a base Operation type, e.g. AddTableOperation

  2. object-building methods in operations move to a utility object "objects" or similar, e.g. _table(), _metadata(), _unique_constraint();

  3. 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()".

  4. 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.

  5. autogenerate api -> _produce_commands will deal in these directives now. the directives are first generated from the diffs stream

  6. the Operation objects also store a reference to the diff object they got from the diffs stream,

  7. 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.

  8. extensibility is key so ensure Operation objects have an .info as well.

  9. 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.

  10. operations.BatchOperations subclass probably needs to stay as is for now

see also #301

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Jul 3, 2015

Michael Bayer (@zzzeek) wrote:

  • squash merge of ticket_302 branch
  • 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 #302
  • The internal system for autogenerate been reworked to build upon
    the extensible system of operation objects present in #302.
    A new customization hook process_revision_directives is added
    to allow manipulation of the autogen stream. Fixes #301

0e43247

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Jul 3, 2015

Changes by Michael Bayer (@zzzeek):

  • changed status to closed
@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Jul 3, 2015

Michael Bayer (@zzzeek) wrote:

  • add the .info dictionary, references #302

37ec812

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment