"alembic downgrade 2618d46ca35c --sql" does not work

[sqlalchemy-bot]

Migrated issue, originally created by ElGans (@delegans)

does not work:

alembic downgrade 2618d46ca35c --sql
...
AttributeError: 'NoneType' object has no attribute 'module'

but this is ok:

alembic downgrade 2618d46ca35c

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

[[https://bitbucket.org/zzzeek/alembic/changeset/046d0b701b921d0167c04fe8c9dfd8c41ec21ecd|046d0b701b921d0167c04fe8c9dfd8c41ec21ecd]]

[sqlalchemy-bot]

Changes by Michael Bayer (@zzzeek):

• changed status to closed

[sqlalchemy-bot]

ElGans (@delegans) wrote:

Thanks for a quick response.

Now when I downgrade with --sql option:

alembic downgrade 2618d46ca35c --sql

INFO  [alembic.migration] Context impl OracleImpl.
INFO  [alembic.migration] Generating static SQL
INFO  [alembic.migration] Will assume transactional DDL.
SET TRANSACTION READ WRITE

/

Revision 2618d46ca35c is not an ancestor of base

But downgrade without --sql option successfully done:

INFO  [alembic.migration] Context impl OracleImpl.
INFO  [alembic.migration] Will assume transactional DDL.
INFO  [alembic.migration] Running downgrade 477a76ebfda8 -> 2618d46ca35c

Is it bug?

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

nope, the first arg when using --sql is implicitly "base" if not given as :. I'd rather keep this explicit in the downgrade case.

[sqlalchemy-bot]

ElGans (@delegans) wrote:

How do I get downgrade sql now?

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

combining http://alembic.readthedocs.org/en/latest/tutorial.html#getting-the-start-version as well as that "base" and "head" represent the start and end sequences (http://alembic.readthedocs.org/en/latest/tutorial.html#downgrading) you'd use "downgrade 261:base --sql"

[sqlalchemy-bot]

ElGans (@delegans) wrote:

Thank you! It works. Not quite intuitive, though.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

--sql requests should really always have the ":". there's no database connection with which to check the current version.

[sqlalchemy-bot]

ElGans (@delegans) wrote:

It's strange a bit for me. Why need to database connect and check the current version if I want to see sql of only one revision?

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

"alembic upgrade|downgrade " means, "upgrade or downgrade the database, starting at the current database's version and stepping to version ". --sql mode then augments this, "instead of connecting to the database, let me specify the starting version". It would be inconsistent for "alembic upgrade --sql" to change the meaning of to be "from current rev to " to only mean "only rev ". Right now, "alembic upgrade --sql" assumes base to be the starting rev.

really, the only change I'd make here if any would be to not have "base" be implicit in the upgrade path. explicit is better than implicit. this confusion wouldn't be occurring.

[sqlalchemy-bot]

ElGans (@delegans) wrote:

You right. explicit is better than implicit - it's true.
methinks it's looks like powerful vi ranges: http://vim.wikia.com/wiki/Ranges

[sqlalchemy-bot]

Robert Buchholz (@rbuchholz) wrote:

Agreed on the explicit path, but please make the error message more informative then. Something along the lines of "Always specify a revision to downgrade from". Downgrading from base never makes sense.

Regarding the issue in particular: As --sql will create offline statements for review anyway, I think assuming a downgrade from head is sensible and consistent with assuming an upgrade from base.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

the assumption of "base" in the upgrade case is slightly different from the assumption of "head" in the downgrade case. "base" means, "the database is as of yet unrevisioned", and is what we assume when the database doesn't yet have an alembic version table.

the message is in 5c673ed.