Postgres requires resetting the sequences I believe. I just assume Oracle/MSSQL are probably similar.
Regarding the signals, basically we have a bunch of post_save type things, which tend to store aggregate data for certain conditions. These get populated (in some cases) in our tests, but don't correspond to a fixture or a model in the same app. -- David Cramer http://justcramer.com On Mon, May 16, 2011 at 9:09 PM, Erik Rose <[email protected]> wrote: > Woo, thanks for the constructive suggestions! > >> Also, one thing I'm quickly noticing (I'm a bit confused why its >> setup_class and not setUpClass as well), > > I was writing to nose's hooks; didn't realize Django used unittest2 now! > >> but this wont work with >> postgres without changing the DELETE code to work like the test >> runner's TRUNCATE foo, bar; (due to foreign key constraints). > > Absolutely. I assume this is what you fix below.... > >> You can do something like this to handle the >> flushing: >> >> sql_list = connection.ops.sql_flush(no_style(), >> tables, connection.introspection.sequence_list()) >> for sql in sql_list: >> cursor.execute(sql) > > Brilliant! Thanks! Say, can you think of any backends in which you actually > have to reset the sequences after truncating? That seems like an interesting > decoupling to me. MySQL, anyway, does the reset implicitly; perhaps we can > optimize its sql_flush routine. > >> Unfortunately, you're still reliant that nothing was created with >> signals that uses constraints. For us this is very common, and I can't >> imagine we're an edge case there > > Can you tell me of these signals? Which ones? I don't think we use them, but > I don't want to overlook them. > > Erik -- 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.
