> > This comes up every once in a while, and every once in a while I post a > link to my solution to this issue from a while back: > > http://code.djangoproject.com/ticket/1007 > > This patch, while it might need some small tweaks to work against > recent trunks, lets you essentially turn this behavior off for specific > objects, while retaining some of the behavior where it is desired. >
Actually I did see this patch and looked through it. It is certainly the right thing to do for MySql type databases that have no built in RI (by default, I know that you can use innodb). This gives them the option of a "delete restrict" functionality. This patch ought to make its way into the core code to support those types of database. However, it is still the WRONG thing to do for databases that properly support RI. All that needs to be done in those cases is to try and delete the record. If the database has specified delete cascade then all works. If there is a "delete restrict" *anywhere in the chain* then an error will occur that needs to be handled. To do it the way you propose is potentially very inefficient. If I have a table with 10 million rows, the last thing I want is some high level code trawling through it to find out if any rows with a particular reference exist. The database engine is much more efficient at that. I still think that the only way to do it is to flag (possibly in the db backend module) that RI is properly supported and to honour that by not even trying to remove/discover dependent relations. Database engines such as PostgreSQL and SQLServer etc. have had enormous amounts of testing, putting huge empahsis on data integrity and efficiency. I'm not sure why many of the ORMs out there (Django is not alone in this) presume that thay know better and trample all over a carefully designed database. To make matters worse, the delete logic in Django is not even done in a transaction by default. What happens if it gets part way though deleting thousands of dependent rows and an error occurs, or some delete is stopped by a trigger or some such? Scrap one database. Obviously anyone with an ounce of intelligence is going to run their valuable database with transactions on, which will mitigate this latter problem to a large extent. Probably a warning in the docs? (rant mode off :) ) 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 -~----------~----~----~----~------~----~------~--~---
