Bug description
I am booting up official release tag (TAG=5.0.0rc3) with docker compose with database metadata for Azure MYSQL Instance I am overriding .env.local configuration as DATABASE_PORT=3306 DATABASE_DIALECT=mysql+mysqlconnector DATABASE_HOST=xxxx.mysql.database.azure.com DATABASE_DB=superset DATABASE_PASSWORD=yyyyy DATABASE_USER=superset
superset_init container starts Applying DB migrations as below
superset_init | ###################################################################### superset_init | Init Step 1/4 [Starting] -- Applying DB migrations superset_init | ###################################################################### superset_init | Loaded your LOCAL configuration at [/app/docker/pythonpath_dev/superset_config.py] superset_init | 2025-06-22 10:38:54,962:INFO:superset.initialization:Setting database isolation level to READ COMMITTED superset_init | 2025-06-22 10:38:55,393:INFO:mysql.connector:package: mysql.connector.plugins superset_init | 2025-06-22 10:38:55,393:INFO:mysql.connector:plugin_name: mysql_native_password superset_init | 2025-06-22 10:38:55,394:INFO:mysql.connector:AUTHENTICATION_PLUGIN_CLASS: MySQLNativePasswordAuthPlugin superset_init | 2025-06-22 10:38:59,275:INFO:superset.utils.screenshots:No PIL installation found superset_init | 2025-06-22 10:38:59,895:INFO:superset.utils.pdf:No PIL installation found superset_init | INFO [alembic.env] Starting the migration scripts. superset_init | INFO [alembic.runtime.migration] Context impl MySQLImpl. superset_init | INFO [alembic.runtime.migration] Will assume transactional DDL. superset_init | INFO [alembic.runtime.migration] Running upgrade -> 4e6a06bad7a8, Init
but fails at the migration on below mysql.connector.errors.ProgrammingError: Failed processing pyformat-parameters; Python 'reportstate' cannot be converted to a MySQL type
superset_init | INFO [alembic.runtime.migration] Running upgrade 9d8a8d575284 -> cecc6bf46990, rm_time_range_endpoints_2
superset_init | INFO [alembic.runtime.migration] Running upgrade cecc6bf46990 -> ad07e4fdbaba, rm_time_range_endpoints_from_qc_3
superset_init | slices updated with no time_range_endpoints: 0
superset_init | INFO [alembic.runtime.migration] Running upgrade ad07e4fdbaba -> a9422eeaae74, new_dataset_models_take_2
superset_init | >> Assign new UUIDs to tables...
superset_init | >> Drop intermediate columns...
superset_init | INFO [alembic.runtime.migration] Running upgrade a9422eeaae74 -> cbe71abde154, fix report schedule and execution log
superset_init | Traceback (most recent call last):
superset_init | File "/app/.venv/lib/python3.10/site-packages/mysql/connector/cursor.py", line 285, in process_params_dict
superset_init | conv = to_mysql(conv)
superset_init | File "/app/.venv/lib/python3.10/site-packages/mysql/connector/conversion.py", line 245, in to_mysql
superset_init | raise TypeError(
superset_init | TypeError: Python 'reportstate' cannot be converted to a MySQL type
superset_init |
superset_init | The above exception was the direct cause of the following exception:
superset_init |
superset_init | Traceback (most recent call last):
superset_init | File "/app/.venv/lib/python3.10/site-packages/sqlalchemy/engine/base.py", line 1910, in _execute_context
superset_init | self.dialect.do_execute(
superset_init | File "/app/.venv/lib/python3.10/site-packages/sqlalchemy/engine/default.py", line 736, in do_execute
superset_init | cursor.execute(statement, parameters)
superset_init | File "/app/.venv/lib/python3.10/site-packages/mysql/connector/cursor.py", line 389, in execute
superset_init | stmt = _bytestr_format_dict(stmt, self._process_params_dict(params))
superset_init | File "/app/.venv/lib/python3.10/site-packages/mysql/connector/cursor.py", line 291, in _process_params_dict
superset_init | raise ProgrammingError(
superset_init | mysql.connector.errors.ProgrammingError: Failed processing pyformat-parameters; Python 'reportstate' cannot be converted to a MySQL type
superset_init |
superset_init | The above exception was the direct cause of the following exception:
superset_init |
superset_init | Traceback (most recent call last):
superset_init | File "/app/.venv/bin/superset", line 10, in last_value AS report_schedule_last_value, report_schedule.last_value_row_json AS report_schedule_last_value_row_json
superset_init | FROM report_schedule
superset_init | WHERE report_schedule.last_state = %(last_state_1)s]
superset_init | [parameters: {'last_state_1':
what is the resolution for this?
Screenshots/recordings
No response
Superset version
master / latest-dev
Python version
3.9
Node version
16
Browser
Chrome
Additional context
No response
Checklist
- [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [ ] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.
Comment From: dosubot[bot]
Hi @shyamalshivam! I'm Dosu and I’m helping the superset team.
This migration error happens because the migration script passes a Python Enum (ReportState.WORKING) directly to a query filter, but the underlying database column is a string. The mysql-connector-python driver (used with DATABASE_DIALECT=mysql+mysqlconnector) can't convert the Enum to a string, which causes the failure. This is not specific to Azure MySQL—it's a general compatibility issue with this driver and Enum handling in SQLAlchemy migrations.
There are two main workarounds:
- Edit the migration script at superset/migrations/versions/2022-05-03_19-39_cbe71abde154_fix_report_schedule_and_log.py and change any usage of ReportState.WORKING to ReportState.WORKING.value in the query filter. This ensures a string is passed to the database, not the Enum object.
- Switch your SQLAlchemy connection driver to mysqlclient instead of mysql-connector-python. This can be done by setting DATABASE_DIALECT to mysql+mysqldb in your .env.local. The mysqlclient driver handles Enum conversion more gracefully and avoids this error (reference).
No official fix or patch for this specific migration script has been merged yet, but this workaround is well understood in the community. Let me know if you need the exact code change for the migration script.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other 
Comment From: shyamalshivam
Hi @dosu it is working but these are below few files, needs to be changed to make it work. Also I need to create a file requirements-local.txt file to install mysql-connector-python like below
touch docker/requirements-local.txt echo "mysql-connector-python" >> docker/requirements-local.txt
all below files needs to be changed to make it work. modified: docker-compose-non-dev.yml modified: superset/daos/chart.py modified: superset/daos/dashboard.py modified: superset/examples/birth_names.py modified: superset/examples/country_map.py modified: superset/examples/deck.py modified: superset/examples/energy.py modified: superset/examples/long_lat.py modified: superset/examples/multiformat_time_series.py modified: superset/examples/random_time_series.py modified: superset/examples/supported_charts_dashboard.py modified: superset/examples/world_bank.py modified: superset/migrations/versions/2022-05-03_19-39_cbe71abde154_fix_report_schedule_and_log.py modified: tests/integration_tests/charts/api_tests.py modified: tests/integration_tests/dashboards/api_tests.py
Comment From: dosubot[bot]
Glad to hear you got it working! The core Enum-to-MySQL compatibility issue is isolated to the migration script—specifically, you need to use Enum.value (like ReportState.WORKING.value) in SQLAlchemy queries when the DB column is a string. This is a known issue with mysql-connector-python and has been discussed in the community; switching to mysqlclient is another workaround if you want to avoid these changes in the future (reference).
For the other files you listed (DAOs, examples, tests), there’s no evidence they require Enum-related changes for this issue—unless they also query string columns using Enums directly, which is uncommon outside migrations. Most changes in those files are likely related to ensuring driver compatibility, data loading, or test setup, not Enum handling.
Best practice: always use Enum.value in queries against string columns, document your local changes, and keep an eye on upstream for any fixes. If you want a detailed review or explanation of changes in any specific file, let me know!
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
Comment From: rusackas
Is this still an issue we should keep open? It sounds like things were resolved, but it also sounds like a PR may be warranted. Let us know!