Ticket 7539: Add ON DELETE and ON UPDATE support to Django
Michael Glassford
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?
As a refresher, this patch:
a) Extends Django's built in ON DELETE CASCADE emulation to include ON
DELETE RESTRICT and ON DELETE SET NULL emulation. These new behaviors
can be selected on a field-by-field basis (specified by attributes in
the ForeignKey definition) or can be specified as the default behavior
(by adding a settting to the settings file).
b) Optionally extends Django's SQL generation to include ON DELETE
CASCADE / RESTRICT / SET NULL and ON UPDATE CASCADE / RESTRICT / SET
NULL clauses in the generated FOREIGN KEY definitions.
Mike
Russell Keith-Magee
>
> 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.
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 migration path
from current behaviour to the new behaviour will also need to be very
clear.
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.
Yours,
Russ Magee %-)
Michael Glassford
Russell Keith-Magee wrote:
> On Fri, Feb 20, 2009 at 1:49 AM, Michael Glassford <glassfordm-Re5JQ...@public.gmane.org> 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
Michael Glassford
> On Fri, Feb 20, 2009 at 1:49 AM, Michael Glassford <glass...@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.