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
-~----------~----~----~----~------~----~------~--~---

Reply via email to