Databases
StackOverflow2013
Postsdbo
POIs Django supposed to implement DB on_delete rules itself?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POIs Django supposed to implement DB on_delete rules itself?
    primarykey
    data
    text
    <p>I have a Django 1.3 app for which I am using South 0.7.3 for DB migrations. I have a problem where an <code>on_delete=models.SET_NULL</code> rule doesn't seem to be firing when the parent entity is deleted, thus giving me a constraint violation from the underlying DB (which is Postgres 8.4).</p> <p>The relevant parts of the entity defns are:</p> <pre><code>class AccessPeriod: .... class Payment: period = models.ForeignKey( AccessPeriod, related_name = "payments", db_index = True, null = True, on_delete = models.SET_NULL ) </code></pre> <p>After some digging, I discovered that South doesn't actually insert the <code>ON DELETE</code> clause into the SQL it generates for migrations, so the DB is definitely not going to do the nullifying on the broken relationships itself:</p> <p><a href="http://south.aeracode.org/ticket/763">http://south.aeracode.org/ticket/763</a></p> <p>Then I read the Django docs for on_delete rules, which state (my emphasis):</p> <blockquote> <p>When an object referenced by a ForeignKey is deleted, Django by default <strong>emulates</strong> the behavior of the SQL constraint ON DELETE CASCADE and also deletes the object containing the ForeignKey. This behavior can be overridden by specifying the on_delete argument.</p> </blockquote> <p>The "emulates" part suggested to me that Django tries to implement the on_delete behaviour itself and does not rely on the underlying DB to automatically execute this as part of the transaction, thus making the South bug irrelevant.</p> <p>I had a poke through <code>db/models/deletion.py</code> in the Django source and based on the implementation of <code>SET()</code> / <code>SET_NULL()</code> and <code>collect()</code> it certainly seems like Django is supposed to do this itself, however, if I try to delete an AccessPeriod from the Django admin, I get constraint violations on the Payments table for the ID it still references which is now deleted, i.e. it doesn't seem like Django is calling <code>SET_NULL()</code> on the <code>Payment.period</code> relationship as part of the call to <code>accessPeriod.delete()</code>.</p> <p>Am I doing something wrong here, or misunderstanding what Django should be doing? Just trying to avoid manually hacking the DB to insert the ON DELETE rule myself, which feels extremely brittle and horrible.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USglenc
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POIs Django supposed to implement DB on_delete rules itself?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POIs Django supposed to implement DB on_delete rules itself?
      1. USbouke
      1. VTBountyStart
    3. VO
      singulars
      1. POIs Django supposed to implement DB on_delete rules itself?
      1. This table or related slice is empty.
      1. VTUpMod
    1. COIf you get a stack trace from when postgres fails, maybe that will have a clue as to where it's going wrong. It might be something that you overlooked.
      singulars
      1. POIs Django supposed to implement DB on_delete rules itself?
      1. USleech
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload