Skip to content
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

Hard to use ops outside of alembic scripts #19

Closed
sqlalchemy-bot opened this issue Jan 3, 2012 · 9 comments
Closed

Hard to use ops outside of alembic scripts #19

sqlalchemy-bot opened this issue Jan 3, 2012 · 9 comments
Labels
Milestone

Comments

@sqlalchemy-bot
Copy link

@sqlalchemy-bot sqlalchemy-bot commented Jan 3, 2012

Migrated issue, originally created by Wichert Akkerman (@wichert)

I already have a simple upgrade framework that I want to keep using, but the operations implemented by alembic are very useful (and look saner than sqlalchemy-migrate), so I'm interested in using just the underlying alembic ops. This appears to be hard to do: the operations require a global context, but there is no API to configure that. This seems to at get some things going:

#!python
from alembic import context
from alembic.config import Config

config = Config(None)
context._opts(config, None, fn=None)
connection = meta.Session.connection()
context.configure(connection=connection, target_metadata=meta.metadata)

but it feels like API abuse to do it this way.


Attachments: 19.patch

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Jan 3, 2012

Michael Bayer (@zzzeek) wrote:

The ops are based on a global context and that's not suitable to export as a standalone API right now. I had in mind folks could use the constructs inside of alembic.ddl though.

But you want all the automatic crap. So the attached patch starts, you'd call:

#!python

engine = create_engine("postgresql://scott:tiger@localhost/test", echo=True)
connection = engine.connect()

impl = ddl.ops_for_connection(connection)

impl.add_column("sometable", Column("somecolumn", Integer))

but then the code would have to be refactored such that all the "macro" behavior of alembic.op moves to alembic.ddl.impl.

It would be better if you just moved your stuff from Migrate to Alembic fully.

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Jan 3, 2012

Changes by Michael Bayer (@zzzeek):

  • attached file 19.patch
@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Jan 3, 2012

Wichert Akkerman (@wichert) wrote:

There are a few reasons I prefer our current upgrade framework:

  • we use introspection to figure out what steps to run, instead of relying on version numbers, which removes the need to keep track of version numbers or any other upgrade-machinery specific state. The upgrade mini-framework will simply run all known upgrade steps and rely on them to be idempotent.
  • it has a simple system where upgrade steps can declare specific environments, which works for non-SQL systems as well.

In case you are interested our upgrade mini-framework is available at https://github.com/2style4you/s4u.upgrade . An example of hooking SQLAlchemy into it can be found at https://github.com/2style4you/s4u.sqlalchemy/blob/master/src/s4u/sqlalchemy/upgrade.py .

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Jan 3, 2012

Michael Bayer (@zzzeek) wrote:

basically op.py would get everything moved to a new class Operations, then that can be instantiated for a particular impl, then we put some kind of helper function like ops_for_connection() to provide it. The tedious part then is having two of each function in op.py, the module level add_column() and the Operations level add_column(). We'd probably have op.add_column() document "see Operations.add_column()" for the documentation.

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Jan 24, 2012

Michael Bayer (@zzzeek) wrote:

OK you can see where I'm going with this in https://bitbucket.org/zzzeek/alembic-api-2-refactor. The only hard break is that "alembic.context" and "alembic.op" aren't modules anymore, so we'll make it 0.2 for that. Other than those two, which are established and torn down within the scope of a context manager, everything is non-global now and there is now a clean chain of objects with EnvironmentContext -> MigrationContext -> Operations. You can have MigrationContext without the EnvironmentContext also and I'll be making things more independent as this continues.

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Jan 24, 2012

Changes by Michael Bayer (@zzzeek):

  • set milestone to "0.2.0"
@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Jan 24, 2012

Michael Bayer (@zzzeek) wrote:

I've merged that fork back into the mainline. 0.1 is now branched off.

It would be very helpful if you could review where I've gone with this, there's an arch diagram at http://alembic.readthedocs.org/en/latest/api.html . There's no longer reliance on globals, except for the "alembic.op" and "alembic.context" symbols made available to an env.py/migration script environment. I haven't built out tests for your case specifically yet, but you'd be looking to call MigrationContext.configure(), then pass that to the constructor of Operations. You shouldn't need the EnvironmentContext object at all. That's the goal anyway.

Things are looking a bit more enterprisey but I'm hoping this exposes the maximum functionality in the most portable way. All tests are passing here and some field testing indicates everything seems to be working also.

Anyway this is what 0.2 will look like unless you need me to make more adjustments, so let me know !

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Jan 30, 2012

Michael Bayer (@zzzeek) wrote:

OK as of [[https://bitbucket.org/zzzeek/alembic/changeset/68d380135c752e9bb1054ee0126269b9d64f6ebe|68d380135c752e9bb1054ee0126269b9d64f6ebe]] you can say:

#!python

env = MigrationContext.configure(connection)

op = Operations(env)

op.alter_column("t", "c", nullable=True)

based on your feed back I'll consider this resolved thanks !

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Jan 30, 2012

Changes by Michael Bayer (@zzzeek):

  • changed status to closed
@sqlalchemy-bot sqlalchemy-bot added this to the 0.2.0 milestone Nov 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.