On May 8, 7:16 pm, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > On Sun, May 8, 2011 at 4:25 PM, Adam Seering <aseer...@gmail.com> wrote: > > I have some Python code that generatesinitialdatafor some of my tables; I > > currently call that code from a post_syncdb hook. In Django 1.3, it looks > > like > > Django now calls TRUNCATE (or an equivalent non-PostgreSQL-ism) on all > > tables > > after running syncdb and all of itspost- hooks. > > That... doesn't sound right. Here's all the SQL syncdb executes (for a > simple app with one table); notice the distinct lack of any TRUNCATE > statement. > > Are you perhaps talking about doing this during testing? If so, you're > looking for unittest's setUp > method:http://docs.python.org/library/unittest.html#unittest.TestCase.setUp.
Oh, sorry, yeah; let me clarify: Our code has initial database data that it needs in general to operate as intended, during tests or otherwise. Mostly (though not exclusively) to do with a plugins system; scanning a subdirectory for matching .py files and detecting the features that they export is a little expensive, particularly in the critical path of page-rendering; much faster to do it once in advance. The TRUNCATE is during tests, though. If we were to use TestCase.setUp, I would need to modify each of our test classes to call each of our post_syncdb data-set-up hooks. This seems inelegant somehow; someone's going to forget one, and it's redundant work (and so slower tests) because most of our tests aren't TransactionTestCases and so don't need to re-create all of the data. I could monkeypatch TestCase, and possibly even patch some hooks into django.core.management.flush.Command.handle_noargs or django.db.backends.*.DatabaseOperations.sql_flush to know when data has been flushed so that I don't have to restore it unnecessarily. That feels complicated and fragile, though; I'm not a fan if I can avoid it... If the appropriate signals existed in the test framework, I could hook them and do something mildly creative and achieve the same effect as the above using public API's and no monkeypatching. Unfortunately, it looks like they don't exist just yet; I just gave Trac #14319 a gentle poke along those lines. All of these seem way too complicated, though. Am I missing the forest for the trees?; is there a simpler solution here? Thanks, Adam (Incidentally, sorry if this is a duplicate; my original reply, identical text, doesn't show up on groups.google.com...) -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
