On Tuesday 12 September 2006 21:30, James Bennett wrote: > There are some checks in place for this; the admin app, for example, > will display a confirmation page before allowing a delete, and that > page lists every related object that will be deleted.
You mean every TYPE of object surely. I'd like to see it list 10 million records :) Even so, if the user selects YES, I'd still be pretty upset. Personally I like the database to have the last word in this case for what can be deleted and what can't. > Much of the problem with this is that certain databases > *cough*sqlite*cough*mysql*cough* have issues with specifying delete > behavior at the SQL level. I've written this up at some length on the > Django developers list[1], but here's the executive summary: I understand this, but I'm not sure why Django has to be broken to accommodate these databases. As I said, if the database cannot support proper foreign keys, then fall back to the sledge hammer cascade delete approach, otherwise do the right, and simpler thing. > * Postgres is the only DB which supports the full range of "ON DELETE" > and "ON UPDATE" options consistently. And SQLServer and Sybase (Enterprise and SQLAnywhere) and Oracle and ... I know that Django doesn't support them all (yet), but people do use them a bit. > If you read through the referenced thread, there's discussion of some > options but it's a tough problem that we don't yet have a good > solution for. > I think that previous discussion overcomplicates this. I think there is a simple solution, at least in principle. If the database backend supports proper foreign relationships, don't "smartly" try to follow them on delete in code, let the database "do its thing". Probably a simple switch + error catch. If the database doesn't support proper foreign keys, then do the current behaviour. If the database DOES support proper foreign keys, then Django should not try to compensate for poor database design! As you say there is no way in fact that you can define a foreign key relationship in Postgres that would leave a "dangling" record. The relationship is either restrict (the default), cascade or set null. This is true of most databases that are not MySql or SqlLite. I'm sorry if I come over a bit antagonistic here, I don't mean to, but to me this is fundamental good database design and behaviour. I'm not yet familiar enough with the Django code to offer a true solution (simple or not), but I'm quite willing to debate the issues and possible solutions. Regards, Gary --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
