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|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||yes||Patch needs improvement:||no|
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.
Change History (6)
Changed 7 years ago by psmith
comment:1 Changed 7 years ago by Alex
- Needs documentation unset
- Needs tests unset
- Patch needs improvement unset
- Triage Stage changed from Unreviewed to Accepted