On Mon, Jun 20, 2011 at 10:57 PM, Benedict Holland <benedict.m.holl...@gmail.com> wrote: > I ran into a problem with running unit tests against views where it > said that: > > HINT: Truncate table "challenges_challenge_attachments" at the same > time, or use TRUNCATE ... CASCADE. > > I patched it to be this, only for postgresql. This patch seems to work > quite well. I don't know if there are any pitfalls but this allowed me > to create my own views using the unmanaged model and still test > successfully with foreign keys.
Sounds to me like you might have found an interesting edge case. The current truncation behavior acts on all managed models to flush out data as part of the testing process. Unmanaged models are ignored as part of this flushing process. Of course, this means that if you have an unmanaged model with a foreign key to the managed model, there will be dangling references. The problem here is that Django's interpretation of "unmanaged" has historically been "we won't touch it", because we have no way of knowing if the data in the unmanaged table can be safely flushed. Unmanaged models are sometimes used to represent tables of static data which Django can't manipulate, for example. While I don't doubt that the patch you've provided fixes your specific problem, I'm not convinced it's necessarily the right solution in the general case. For example, just flushing the unmanaged model won't always be sufficient -- if you have another database table that isn't referenced by Django with a foreign key on the unmanaged model, *that* table will also need to be truncated - but Django will have no visibility on that table. My immediate reaction is that this sounds like we need some sort of ability to manually specify extra commands to issue during a flush. However, there may be other options that I haven't considered. Suggestions are welcome. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
