On 1/20/06, hugo <[EMAIL PROTECTED]> wrote: > BTW: the bulk delete stuff can be made more complete database-wise by > using the delete sql clause to construct deletes against related tables > (and doing updates against related tables).
I have no difficulty in seeing how it _can_ be done. However, I am still wondering if it _should_ be done. It certainly can't be done efficiently - at least, nowhere near as efficiently as a single line SQL query would handle it. The more I look at the problem, the worse things get. There are all sorts of edge cases that the existing implementation doesn't handle. For example, if you delete an object that is referenced from a ForeignKey field, the ForeignKey is set to NULL. But what if that field is marked NOT NULL? In the current implementation, the stale key remains in the referencing field. Referential integrity is supported by PostgreSQL, MSSQL, Oracle, and MySQL 5. This referential integrity is debugged, tested, efficient, and flexible. It might be possible to fake referential integrity in SQLite2.5+ using triggers. At the moment, the FAQ doesn't set any minimum version numbers on any database backend. I would suggest that it should. Yes, this means that people with MySQL 3/4 databases will need to upgrade or choose another database. But why should we spend so much time and effort writing, testing, and debugging a reimplementation of referential integrity in Django simply to support those who come to Django asking "Hey, I've got this nail; how do I use this bratwurst as a hammer?". Django is a complex enough without complicating the problem by reimplementing half the features of a database to support those in the community that can't/won't upgrade. Russ Magee %-)
