SQLAlchemy 1.4 "operator does not exist" errors with pg8000
Question:
It seems that the previous versions we were on (SQLAlchemy 1.3.23) automatically coerced strings to the appropriate variable type for the query. For example:
session.query(my_data).filter(my_data.the_date = '2022-07-01').all()
‘2022-07-01’ would be coerced to a date type automatically. Now I am getting a ton of of errors like the following
operator does not exist: timestamp without time zone = character varying
I would like to avoid going through our code base and changing all of these cases by using date objects, etc… instead of strings. I am surprised I am not find more on this issue. Is there some setting in SQLAlchemy that allows strings to be coerced? Or maybe some other solution?
Answers:
SQLAlchemy 1.4+ requires pg8000 version 1.16.6 or later and that version of pg8000 also seems to have made some other breaking changes, apparently including the way that string literals are handled in comparisons to date/timestamp columns.
If you want to reduce the changes in your code to avoid those errors with SQLA 1.4 you might consider switching to postgresql+psycopg2://.
It seems that the previous versions we were on (SQLAlchemy 1.3.23) automatically coerced strings to the appropriate variable type for the query. For example:
session.query(my_data).filter(my_data.the_date = '2022-07-01').all()
‘2022-07-01’ would be coerced to a date type automatically. Now I am getting a ton of of errors like the following
operator does not exist: timestamp without time zone = character varying
I would like to avoid going through our code base and changing all of these cases by using date objects, etc… instead of strings. I am surprised I am not find more on this issue. Is there some setting in SQLAlchemy that allows strings to be coerced? Or maybe some other solution?
SQLAlchemy 1.4+ requires pg8000 version 1.16.6 or later and that version of pg8000 also seems to have made some other breaking changes, apparently including the way that string literals are handled in comparisons to date/timestamp columns.
If you want to reduce the changes in your code to avoid those errors with SQLA 1.4 you might consider switching to postgresql+psycopg2://.