Open sqlalchemy-bot opened 6 years ago
Michael Bayer (@zzzeek) wrote:
hi there -
This is likely not a common use case, since for manual migrations people just log into their database and type ALTER commands.
If you want to run op statements in a shell, follow the example at https://alembic.zzzcomputing.com/en/latest/ops.html#alembic.operations.Operations.
Here it is in context:
Python 3.7.0 (default, Jun 28 2018, 10:59:55)
[GCC 8.1.1 20180502 (Red Hat 8.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from alembic.migration import MigrationContext
>>> from alembic.operations import Operations
>>> from sqlalchemy import create_engine
>>> e = create_engine("sqlite://", echo=True)
>>> conn = e.connect()
2018-11-17 09:45:59,669 INFO sqlalchemy.engine.base.Engine SELECT CAST('test plain returns' AS VARCHAR(60)) AS anon_1
2018-11-17 09:45:59,669 INFO sqlalchemy.engine.base.Engine ()
2018-11-17 09:45:59,671 INFO sqlalchemy.engine.base.Engine SELECT CAST('test unicode returns' AS VARCHAR(60)) AS anon_1
2018-11-17 09:45:59,671 INFO sqlalchemy.engine.base.Engine ()
>>> ctx = MigrationContext.configure(conn)
>>> op = Operations(ctx)
>>> from sqlalchemy import Column, Integer
>>> op.create_table("mytable", Column('x', Integer))
2018-11-17 09:46:32,202 INFO sqlalchemy.engine.base.Engine
CREATE TABLE mytable (
x INTEGER
)
2018-11-17 09:46:32,202 INFO sqlalchemy.engine.base.Engine ()
2018-11-17 09:46:32,203 INFO sqlalchemy.engine.base.Engine COMMIT
Table('mytable', MetaData(bind=None), Column('x', Integer(), table=<mytable>), schema=None)
does that solve your issue?
Glen Fletcher wrote:
Yes Thank you for the help, that covers what I need but I think you misunderstood what I meant by manual, I want to write a system for plugin management where plugins can define database requirements my code would then use the MigrationContext to make necessary changes to the database. I simply mentioned an interactive session as I was sure that would cover what I wanted. I would suggest adding that session of an example of how to run the database operations directory rather than using the automatic version control the tutorial currently covers. I'm sure there are other users who would find an example how how to setup the MigrationContext and Operations manually useful. This allows people to implement their own version control system to meet the requirements of their project.
Michael Bayer (@zzzeek) wrote:
you're looking for the API. It's documented, extensively, start at https://alembic.zzzcomputing.com/en/latest/api/index.html. the above session is already described in the "Operation Directives" section.
Changes by Glen Fletcher:
Changes by Michael Bayer (@zzzeek):
Changes by Michael Bayer (@zzzeek):
Migrated issue, originally created by Glen Fletcher
I'm not sure whether this is a problem with the documentation or the code. However I suspect its the documentation that is at fault.
The Documentation, only talks about automatic migration using change scripts, however this isn't always an suitable for a problem.
I would like to see a clearly defined may of manually altering a specific database, lets say I have a Database connection through SQLAlchemy, open on an interactive console. I then want to be able run commands like those used in the change scripts to alter the database. I can't find how to achieve this in the documentation. It should be possible since the framework is effectively doing that but it is designed to work from the migration environment rather than explaining how to open the connection from an interactive session, and setup the state so I can run the requited commands to alter the database.
Such functivity is important for plugin based projects where plugins may require extra columns or tables in the database, it this case there is no linear series of versions, as every instance of the application will have different plugins and therefore different database migrations.
Please update the documentation to cover such usage (and if necessary update the code to provide necessary support)