I have a different problem, but the solution to both might be the same. We use a lot of ForeignKeyFields with on_delete=models.DO_NOTHING, since we found the default cascade behaviour dangerous (it was too easy for one ill thought through delete to take out half the database).
I've just been writing a test which checks that a delete() method works correctly. The test passes, but on closer inspection it should have failed, because creating my object creates a second object which is not being deleted. In principle Postgres will raise an IntegrityError about this, but because all foreign keys are created "DEFERRABLE INITIALLY DEFERRED", the check doesn't happen until the transaction is committed... which doesn't happen. If I switch to using TransactionTestCase (which is massively slower), the test fails as expected. I haven't tested this yet, but I suspect that if I modified the Django TestCase code to emit "SET CONSTRAINTS ALL IMMEDIATE;" before it truncates the tables my IntegrityError will be raised. I think it should also tell you about your dangling foreign keys. It would be down to you to remove them, but it avoids having to have Django mess with unmanaged tables. I'll have a play and see how hard it would be. Thanks Peter Russell -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
