Opened 6 years ago

Closed 12 months 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)

ticket_11074_against_r10706.diff (6.0 KB) - added by psmith 6 years ago.

Download all attachments as: .zip

Change History (6)

Changed 6 years ago by psmith

comment:1 Changed 6 years ago by Alex

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 4 years ago by julien

  • Needs tests set
  • Severity set to Normal
  • Type set to Bug

comment:3 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:4 Changed 3 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:5 Changed 12 months ago by aaugustin

  • Resolution set to fixed
  • Status changed from new to 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.

Note: See TracTickets for help on using tickets.
Back to Top