On Wed, Mar 24, 2010 at 6:22 AM, jrs <j...@framemedia.com> wrote: > Another great example... If PostgreSQL has referential integrity on by > default, is django still hammering the db with unnecessary queries?
In this case, for two reasons - MySQL, and generic foreign keys. Fisrtly, we aim to guarantee consistent behavior across database backends. We don't consider referential integrity to be optional, and because MySQL is the lowest common denominator, we need to provide an implementation that adds referential integrity to MySQL. Yes, this means that the PostgreSQL implementation is suboptimal, but it ensures that the same deletion behavior happens everywhere. It also means that the implementation is simpler, since we don't have to make a special case of certain backends. Ideally, when #7539 is added to trunk, we will be able to use the databases cascade when it is available, and manually implement the cascade when it isn't. Secondly, there are times when PostgreSQL's cascading won't quite get the job done -- generic foreign keys aren't foreign keys in Postgres, so PostgreSQL's cascading won't catch them by default. There will always be a manual component to the deletion process. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
