I was looking for a ticket like that. Unfortunately I could see where either behavior is going to be controversial. If you set the foreign key back to null, some people will want it to be deleted. If you delete, some people will prefer it go back to null.
Instead could there be an option on nullable foreign key fields? Default the behavior to the non-destructive setting and then allow people to override it if it should be destructive in their application? Of course, this would amount to introducing a new feature to the 1.0 branch which is probably not what you guys want to do. Maybe a 1.1 feature. I'll shut up now as this discussion clearly belongs in django-dev being discussed by people with more in-depth knowledge than myself ;) Thanks Malcolm. Jon. In the interim, for this project, I'll continue to explicitly set cascading deletes in the db. On Oct 9, 8:12 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Thu, 2008-10-09 at 09:28 -0700, Jon Loyens wrote: > > [...] > > > Is this a bug I'm seeing or am I missing something in either my models > > or configuration? Or do I not understand how ForeignKeys where > > null=True are supposed to work? > > It's possibly a bug. There's a ticket open (#9308) about it. The only > question in my mind is which behaviour to use when deleting (delete > child or not), but raising an integrity error is a bug. > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---