pinax-eventlog: Latest V4.0.1 not working for Mysql Database
Describe the bug
I tried to upgrade to new version pinax-eventlog for my app with djangoV3.0.8
, Python 3.8
,Mysql 5.7.22
and when trying to launch the instance i see this following error. When I looked at the migration file
eventlog.0004_auto_20191205_2033
that is failing on it trying to grab a postgres field/variable (field=django.contrib.postgres.fields.jsonb.JSONField())
which my app doesn’t have
I see this issue with both 3.0.1 and 4.0.1 version and currently i was on v2 which did not had a problem. is there a work around for this?
Applying eventlog.0001_initial... OK
Applying eventlog.0002_auto_20150113_1450... OK
Applying eventlog.0003_auto_20160111_0208... OK
Applying eventlog.0004_auto_20191205_2033...Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/django/db/backends/utils.py", line 86, in _execute
return self.cursor.execute(sql, params)
File "/usr/local/lib/python3.8/site-packages/django/db/backends/mysql/base.py", line 74, in execute
return self.cursor.execute(query, args)
File "/usr/local/lib/python3.8/site-packages/MySQLdb/cursors.py", line 209, in execute
res = self._query(query)
File "/usr/local/lib/python3.8/site-packages/MySQLdb/cursors.py", line 315, in _query
db.query(q)
File "/usr/local/lib/python3.8/site-packages/MySQLdb/connections.py", line 239, in query
_mysql.connection.query(self, query)
MySQLdb._exceptions.ProgrammingError: (1064, "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'jsonb NOT NULL' at line 1")
Reproduce behavior
- Upgrade to new version 4.0.1 build and start the instance and when applying migrations the error occurs
Expected behavior All migrations should apply correctly
Desktop
- Mac
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 18 (12 by maintainers)
@blag has the way forward.
It will require some hours to develop modifications to migration packs 0004 and 0005. And then to test against the two different databases.
I am not that seasoned a hand and I don’t really understand if the concept of “database router” is a simple check of which database is in use from settings.py , or if there’s a deeper django meaning of this term I don’t yet know.
I’d certainly buy them a coffee if they would whip up a modification quicker than I can get to it…