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"... :-) Having a quick poking around the net, it looks like mysql5 supports referential integrity. I also found this page: http://www.justatheory.com/computers/databases/sqlite/foreign_key_triggers.html that talks about a workaround implementation for SQLite 2.5+ using triggers. Nothing in that implementation seems SQLite specific - it might be able to be adapted for MySQL<5 Are you opposed to going back to an in-database model of referential integrity if it turns out this trigger mechanism will work? What do you consider minimum versions that must be supported? Alternatively, are you opposed to a scheme that uses referential integrity if it is available, but falls back on the Python-side implementation if it is not? 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. Russ Magee %-)
