Received: by 10.210.91.17 with SMTP id o17mr276999ebb.13.1235414458002;
        Mon, 23 Feb 2009 10:40:58 -0800 (PST)
Return-Path: <gcpdd-django-develop...@m.gmane.org>
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
        by mx.google.com with ESMTP id 13si747561ewy.2.2009.02.23.10.40.57;
        Mon, 23 Feb 2009 10:40:57 -0800 (PST)
Received-SPF: pass (google.com: domain of gcpdd-django-develop...@m.gmane.org designates 80.91.229.2 as permitted sender) client-ip=80.91.229.2;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of gcpdd-django-develop...@m.gmane.org designates 80.91.229.2 as permitted sender) smtp.mail=gcpdd-django-develop...@m.gmane.org
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1LbfjZ-0000Tu-Oa
	for django-developers@googlegroups.com; Mon, 23 Feb 2009 18:40:53 +0000
Received: from dcvt-69-50-60-112.pivot.net ([69.50.60.112])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <django-developers@googlegroups.com>; Mon, 23 Feb 2009 18:40:53 +0000
Received: from glassfordm by dcvt-69-50-60-112.pivot.net with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <django-developers@googlegroups.com>; Mon, 23 Feb 2009 18:40:53 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: django-developers@googlegroups.com
From:  Michael Glassford <glassfo...@gmail.com>
Subject:  Re: Ticket 7539: Add ON DELETE and ON UPDATE support to Django
Date:  Mon, 23 Feb 2009 13:40:35 -0500
Lines: 66
Message-ID:  <49A2EDA3.8030008@gmail.com>
References:  <gnk2jo$m7q$1@ger.gmane.org> <720ff77c0902230218v68879139p8f92e285aa735311@mail.gmail.com>
Mime-Version:  1.0
Content-Type:  text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding:  7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: dcvt-69-50-60-112.pivot.net
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
In-Reply-To: <720ff77c0902230218v68879139p8f92e285aa735311@mail.gmail.com>
Sender: news <n...@ger.gmane.org>

Russell Keith-Magee wrote:
> On Fri, Feb 20, 2009 at 1:49 AM, Michael Glassford <glassfo...@gmail.com> wrote:
>> Just yesterday I updated the patch attached to
>> http://code.djangoproject.com/ticket/7539 so that it will apply against
>> the current version of Django (the previous patch required Django 0.96).
>> What are the chances of some form of this patch being included in one of
>> the next couple of versions of Django?
> 
> Now isn't the best time to be asking this sort of question. We're in
> the tail end of the v1.1 release cycle, and the everyone whose
> attention you need it concentrating on getting that release out the
> door.

I was aware that v1.1 was in the works, which is why I was only asking 
whether including the patch, or something like it, might be considered 
for a future release. You answered that question below.

> For 10c of personal opinion to tide you over: this is an area where
> improvement is both desirable and possible, but the final form of that
> improvement will require some design work. In this case, a big part of
> the design includes surveying the various database backends to
> establish the level of support for features like ON DELETE RESTRICT et
> al. If we expose a feature into the models and/or ORM, it will need to
> be supported (or emulated) across all the backends. 

The new ON DELETE RESTRICT and ON DELETE SET NULL emulation works 
independently of the back end, as does the new use of an on_delete 
attribute in ForeignKey definitions to choose which behavior is used on 
a key-by-key basis.

Since the emission of ON DELETE and ON UPDATE clauses in 
Django-generated SQL is currently controlled by an entry in the settings 
file, which is the same place where the database backend is selected, a 
minimal implementation (such as the one I've provided in my curent 
patch) could simply assume that if you choose to turn on the new SQL 
generation features you would first have to choose a database backend 
that supports them. Obviously, some research is still necessary to make 
sure that the syntax I've used works with the backends that support ON 
DELETE and ON UPDATE clauses (if not, the patch will need to be changed 
  to select the appropriate syntax for each supported backend).

> The migration path
> from current behaviour to the new behaviour will also need to be very
> clear.

The current strategy I'm using is that nothing changes from the current 
behavior unless explicitly specified; that is, unless a) an on_delete or 
on_update attribute is added to a ForeignKey definition (telling it to 
use the specified behavior rather than the default behavior), or b) an 
entry in the settings file changes the default on_delete emulation from 
CASCADE to RESTRICT or SET NULL, or c) an entry in the settings file 
specifies that the SQL emitted by Django should contain ON DELETE and ON 
UPDATE clauses.

Obviously, different migration strategies could be used instead that 
didn't require as many settings file entries.

> However, now isn't the time for public discussions to sort out these
> details. If you want to do the research and get a proposal ready for
> the v1.2 proposal period, be my guest.

I can bring this up again when 1.1 is out, then.

Thanks for your reply,

Mike