Russell Keith-Magee wrote: > On Fri, Feb 20, 2009 at 1:49 AM, Michael Glassford <[email protected]> > 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
