Opened 15 years ago
Closed 10 years ago
#11074 closed Bug (fixed)
syncdb should execute custom field SQL separately from initial model SQL
Reported by: | psmith | Owned by: | nobody |
---|---|---|---|
Component: | Core (Management commands) | Version: | 1.0 |
Severity: | Normal | Keywords: | syncdb geodjango post_create_sql |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | yes | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Currently, if I have exception-throwing SQL in a <app>/<model>.sql file, this breaks GeoDjango's creation of geometry fields and indexes on ./manage.py syncdb. You wind up with a database table that has the regular Django fields but is missing geometry fields at the end of the syncdb command. This is because GeoDjango's field-specific post-table-creation SQL which actually creates the geometry fields (from the post_create_sql() hook) is lumped in with the initial model SQL. I am proposing that custom field post-table-creation SQL like GeoDjango emits and user-specified initial model SQL in *.sql files be run in separate transactions.
Arguably if my custom initial model SQL is broken then I shouldn't expect syncdb to work cleanly. But it may be surprising that my probably unrelated initial model SQL leaves my GeoDjango model tables (or any model with a custom field that implements post_create_sql()) in an incomplete or undefined state because it happens to be executing in the same transaction as the custom field SQL. syncdb does charge ahead and create as much as possible despite exceptions, so I think one could argue that leaving the database in as consistent a state as possible despite errors is a decent goal.
Attachments (1)
Change History (6)
by , 15 years ago
Attachment: | ticket_11074_against_r10706.diff added |
---|
comment:1 by , 15 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 14 years ago
Needs tests: | set |
---|---|
Severity: | → Normal |
Type: | → Bug |
comment:3 by , 13 years ago
UI/UX: | unset |
---|
comment:5 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
With the new migrations framework, you must use a RunSQL operation in a migration instead of custom SQL.
As a consequence this issue is resolved in Django 1.7.
Change UI/UX from NULL to False.