Re: SQL Referential Integrity (WAS: Bulk delete? on django-users)

[Amit Upadhyay]

On 1/19/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:

On 1/19/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/19/06, Russell Keith-Magee <[EMAIL PROTECTED] > wrote:
> > It seems like most of the internal reference walking logic in the
> > object.delete() call would be eliminated if the foreign key fields
> > were declared ON DELETE CASCADE or ON DELETE SET NULL (as
> > appropriate).
>
> This is exactly what Django used to do, actually, back when it was
> Postgres-only. Such are the compromises of having to support other
> DBs. :-/

Hrrm... /me breaks into verse of "get a real database"... :-)
<snip>
It just seems a waste to give up all the useful, efficient
characteristics of a database like PostgreSQL for the sake of
supporting less featured databases. Any in-code implementation of
something like referential integrity will always be slower and more
bug-prone. Writing an application that avoids using referential
integrity in order to maintain compatibility with less featured
databases seems like asking for trouble, either when a bug in the
referential integrity code bites us, or when the server load becomes
an issue.

What would happen to _pre_delete and _post_delete? If I have "real database", and I after profiling I found a few bulk_delete too ineffecient for my application, what is stopping me from taking the database cursor, and executing the sql myself?

--
Amit Upadhyay
Blog: http://www.rootshell.be/~upadhyay
+91-9867-359-701