You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Auto-generated PostgreSQL code in 1.13.2 contains invalid code causing migrations to fail. This appears to be around Serial columns and appears to be related to the fix implemented in: #1479. I get the log around detecting a serial and omitting it. We have a ton of tables like this, and not all of them are having this behavior. The table definitions haven't changed, and everything works in 1.13.1.
The id columns definitely have a server default set, but all of them do, not just the ones triggering this behavior. I am having trouble figuring out what is different between them. The python definition is the same, and the database definitions appear to be almost identical.
I tried replicating it in a fresh database to generate a minimum code sample, but couldn't replicate the behavior
Expected behavior
Expect no change from previous behavior.
Serial and identity are not exactly same in postgres. Serial column has default value while identity column not.
In table definition id column use identity, but the log suggest column has default value.
Maybe there is mismatch in python definition and database tables.
You can check identity_generation and column_default from information_schema.columns for more infomations.
Describe the bug
Auto-generated PostgreSQL code in 1.13.2 contains invalid code causing migrations to fail. This appears to be around Serial columns and appears to be related to the fix implemented in: #1479. I get the log around detecting a serial and omitting it. We have a ton of tables like this, and not all of them are having this behavior. The table definitions haven't changed, and everything works in 1.13.1.
The id columns definitely have a server default set, but all of them do, not just the ones triggering this behavior. I am having trouble figuring out what is different between them. The python definition is the same, and the database definitions appear to be almost identical.
I tried replicating it in a fresh database to generate a minimum code sample, but couldn't replicate the behavior
Expected behavior
Expect no change from previous behavior.
To Reproduce
Table Definition:
Error
Generated SQL it tries to run during migration is:
ALTER TABLE "GEO" ALTER COLUMN id;
Which doesn't do anything and isn't valid and throws an error.
Versions.
The text was updated successfully, but these errors were encountered: