Forums

Issues with Alembic visibility into database objects when using MySQL

Hello! First off - thank you so much for the free tier on PythonAnywhere! Definitely a blessing for beta-testing before a full go-live.

I recently spent a large amount of time debugging an issue where Alembic (under Flask-Migrate) did not seem to understand that my table model was already created in the database. Despite meticulously configuring everything, Alembic just did not seem to see the table, and kept trying to recreate it - any call to migrate() generated ORM create table statements.

My initial attempts at tweaking Alembic config (importing models directly into env.py even though Flask-Migrate streamlines all of that, checking alembic.ini etc) and supplying args like include_schemas=True, include_name and include_object (callables) to the Migrate constructor that would provide them as as kwargs to the underlying Alembic EnvironmentContext.configure all failed. I even explicitly checked the contents of the metdata before it was used in run_migrations_online in env.py - everything looked right, but Alembic seemed to never be able to find the table when I reloaded the website.

I deep-dived into this issue by modifying Alembic sources directly in site-packages; these edits, along with some of the above ones, are still reflected in my account and the results are in the logs. While doing this I noticed that, when include_schemas=True, the use of the official mysql-connector-python connector would cause SQLAlchemy's inspect() function to return a bytearray instead of a regular list. Bytearrays are unhashable and so cannot be added to a set(), which Alembic tries to do - resulting in a crash. Looks like this was because of an old release of the connector.

My specific issue was resolved by using PyMySQL instead of mysql-connector-python, and I would strongly recommend including it in the haggis and innit batteries-included lists. However, the issue still remains for anyone who would want to use include_schemas=True in Alembic, and monkey-patching the Alembic source is far from ideal.

  • Where are you running your code? A Flask web app, using Flask-Migrate to simplify Alembic configuration.
  • What are you trying to achieve? Understanding if there is an open bug that could affect users who use the free-tier MySQL instance with the recommended mysql-connector-python connector and wish to use Alembic
  • What error message do you see? From my server logs:

    2025-04-07 16:49:02,698: Error running WSGI application 2025-04-07 16:49:02,715: TypeError: unhashable type: 'bytearray'

Could you please confirm if this issue really does exist, and if so - could I raise an enhancement request with SQLAlchemy/Alembic for this? I'd like to do my part towards open-source :)

This is not really a SQLAlchemy or Alembic forum. It would probably be more effective to raise this on a forum specific to those packages.

Understood, thank you. This was more of a request to validate the bug before I raised any enhancement requests - I will just use the logs I have for now for that. Figured I'd make a post anyway to help out anyone who uses the free-tier MySQL instance and runs into something similar.

Have a good one!