unicode literals cause migrations to fail #324
Comments
Changes by Bruk Habtu (@brukhabtu):
|
Changes by Michael Bayer (@zzzeek):
|
Changes by Michael Bayer (@zzzeek):
|
Michael Bayer (@zzzeek) wrote: normally you'd show me the actual rendered script here, I hope you arent running autogenerations into scripts and then straight to your database (docs warn against this) |
Michael Bayer (@zzzeek) wrote: this is in detection. wow OK I totally thought this was something else. |
Changes by Michael Bayer (@zzzeek):
|
Changes by Michael Bayer (@zzzeek):
|
Michael Bayer (@zzzeek) wrote: that string is from repr() because 99% of the time it is used to generate Python code. PG's server default comparison is just an optional hackish feature where you'll note in most cases I can't really fix the issues people have with it. but you're in luck. |
Michael Bayer (@zzzeek) wrote:
→ 1c67b1a |
Changes by Michael Bayer (@zzzeek):
|
Michael Bayer (@zzzeek) wrote: still has many more failure cases. thanks for reporting. |
Migrated issue, originally created by Bruk Habtu (@brukhabtu)
Columns
The server_default unicode literal causes migrations to fail with the following traceback
Removing the unicode_literals import fixes the issue above. Does alembic using repr() on the arguments passed to the the Column.init method? Notice how the string is quoted
'u'application/pdf''
Thanks!
The text was updated successfully, but these errors were encountered: