#25002 closed Bug (fixed)
Postgresql migration fails when changing a CharField to a TimeField
| Reported by: | Dirk Uys | Owned by: | Simon Charette |
|---|---|---|---|
| Component: | Migrations | Version: | dev |
| Severity: | Normal | Keywords: | migrations |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
The code from the migration is as follows:
migrations.AlterField( model_name='studygroup', name='time', field=models.TimeField(), ),
The field used to be a models.CharField()
The error follows:
django.db.utils.ProgrammingError: column "time" cannot be cast automatically to type time without time zone HINT: Specify a USING expression to perform the conversion
I can manually fix this using SQL:
ALTER TABLE "studygroups_studygroup" ALTER COLUMN "time" TYPE time USING "time"::time;
I don't have code with the problem isolated, but this project shows the problem when configured to use postgres. http://github.com/p2pu/knight-app/.
Change History (17)
comment:1 by , 10 years ago
| Component: | Uncategorized → Database layer (models, ORM) |
|---|---|
| Keywords: | migrations added |
| Type: | Uncategorized → Bug |
comment:2 by , 10 years ago
| Description: | modified (diff) |
|---|
comment:3 by , 10 years ago
| Easy pickings: | set |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
| Triage Stage: | Unreviewed → Accepted |
comment:4 by , 10 years ago
| Easy pickings: | unset |
|---|---|
| Has patch: | set |
Not sure if this is something we want to backport to 1.8.x but the added test seems to be passing with the proposed changes.
follow-up: 6 comment:5 by , 10 years ago
| Version: | 1.8 → master |
|---|
I don't thing this bug justifies for backport to 1.8. It's the same behavior on 1.7. Use AddField, RunSQL/RunPython, RemoveField, RenameField for the desired outcome.
That said, there is/was a ticket for VARCHAR/INTEGER conversation on a PK, I think. Do you mind investing that one too. Maybe they can both be closed by this patch?
comment:6 by , 10 years ago
Replying to MarkusH:
That said, there is/was a ticket for
VARCHAR/INTEGERconversation on a PK, I think. Do you mind investing that one too. Maybe they can both be closed by this patch?
I'd like to but I can't find it by searching for tickets with the Migration component.
comment:8 by , 10 years ago
Markus, I'm not sure how I should proceed, do you want me to add an additional test that makes sure an integer field can be converted to a char one? It looks like it's already working from the tests and doesn't require an explicit USING.
comment:9 by , 10 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
comment:11 by , 10 years ago
| Has patch: | unset |
|---|---|
| Resolution: | fixed |
| Status: | closed → new |
| Triage Stage: | Ready for checkin → Accepted |
Error on Oracle for the new test is ORA-01758: table must be empty to add mandatory (NOT NULL) column.
comment:16 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
| Triage Stage: | Accepted → Ready for checkin |
Merged the patch marked as RFC by Shai on Github.
comment:17 by , 8 years ago
| Component: | Database layer (models, ORM) → Migrations |
|---|
I'm not sure this qualify as a bug or an enhancement but a simple fix would be to set
DatabaseSchemaEditor.sql_alter_column_type = "ALTER COLUMN %(column)s TYPE %(type)s USING %(column)s::%(type)s".I'll submit a tentative PR to run the full test suite against CI before adding a test.