On Mon, May 9, 2011 at 12:56 AM, Adam Seering <aseer...@mit.edu> wrote:
> On May 8, 10:53 pm, Karen Tracey <kmtra...@gmail.com> wrote:> > > The change you have noticed is documented in the 1.3 > > backwards-incompatibility list: > http://docs.djangoproject.com/en/1.3/releases/1.3/#use-of-custom-sql-... > > Actually, that's a different issue: I'm not using the custom-SQL > loader, I'm using Python code with the post_syncdb hook. This one > isn't in the backwards-compatibility page as far as I can tell. > > (Was that comment intended to cover this case as well? Maybe a typo > somewhere?) > Hmm, you are right, this change is not supposed to affect data added via post_syncdb handlers. Specifically the change here is: https://code.djangoproject.com/changeset/15239. On an initial read it looks like it might cause post_syncdb-added data to get thrown away, since the post_syncdb signal is sent during the call_command('syncdb'). However, the call_command('flush', ...) that was added after the call_command('syncdb', ...) will also cause that signal to get sent. So your post_syncdb-added data should still be available in your test cases. I've verified via some experiments that if I add a post_syncdb handler that inserts data for one of my apps, that data is available for my test cases. So I'm confused why you are seeing different behavior -- what you are describing happening is not what I observe happening. [snip] > Right now, we're working on adding tests, and on encouraging > developers to write tests for new parts of the code, new apps/code > that are being developed, etc. Right now, as I understand it with > Django's current behavior and our post_syncdb hook setup, we want to > re-load the data in three cases: (1) The current test is the first > test, (2) all prior tests are TestCase (as opposed to > TransactionTestCase) instances, or (3) we are a TransactionTestCase > instance. This is all kind of beside the point since I'm not understanding why your post_syncdb-hander-added data is not available to your tests, but for the record: Worrying about whether a particular test is run first, or is preceded by other tests of a certain kind, is something your code should never have to do (excluding doctests, where Django makes no guarantees that things done by one doctest are invisible to others). It's Django's job to ensure that the database is "clean" when each test starts running. In fact Django will run all TestCase tests before any TransactionTestCase tests (as noted in the doc http://docs.djangoproject.com/en/1.3/topics/testing/#testcase), precisely because the mechanism used to reset the database for these different kinds of tests can't ensure that a TestCase run after a TransactionTestCase will see a "clean" database on start. Django will also ensure that anything changed in the DB (including anything done by setUp) in the first test is undone before the second test runs, so if you did add something to setUp of the first test that could then be seen by the 2nd test to run, that would be a bug in Django's test support. > [snip] > What I personally wish that Django did in this case would be to trust > the data that syncdb puts into the database; do the necessary > bookkeeping to restore it to its initial state at the end of each test > as needed. If I thought it would be accepted, I'd submit a patch. > But if it were that simple, I assume someone would have done it that > way at the start; I don't know enough about this project to understand > the reasoning behind the TRUNCATE here in any case... Hopefully > that'll do a better job framing of what I'd like to accomplish with > our code, though. > > What you describe is exactly what Django does for TestCases: restore the state of the DB to its initial post-syncdb version at the end of the test. It does not do that for TransactionTestCases because that would be prohibitively expensive, and unnecessary given first that TransactionTestCases clear the database on entry and second that Django ensures that all TestCases run before any TranactionTestCases. Django makes no guarantees about the state of the DB for doctests, but they don't seem to factor into your setup? What you are describing happening is contrary to what I observe, and contrary to what Django promises, so it would be helpful if you could gives us some information to recreate the behavior you are seeing. Karen -- http://tracey.org/kmt/ -- 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.
