On Saturday 5 May 2012 at 00:39, Anssi Kääriäinen wrote: > On May 4, 2:30 pm, Karen Tracey <kmtra...@gmail.com (http://gmail.com)> wrote: > Thanks for the link. While reading the previous threads I spotted at > one blocker issue: the first TransactionTestCase will not start with > zeroed database sequence values. To prevent this one would need to > flush the DB before the first TransactionTestCase. In addition, if the > goal is to get rid of test ordering, then one would need to flush > before every test case which isn't good. Getting rid of the > requirement to reset sequences between test cases would be good. > Oracle doesn't reset the sequences reliably currently just for > example. But I don't think we can change that for backwards > compatibility reasons. While tests that rely on sequence values are > IMHO broken, changing this would result in numerous broken tests for > users upgrading Django. Notably normal TestCases do not do sequence > resetting at all currently. > > This is a blocker: why change the flushing from pre-test to post-test > if the end result is that you can't run the tests in arbitrary order > anyways? Or if you want to be able to run them in arbitrary order you > will need to run at least the sequence resets pre-test anyways. > Resetting sequences can be really expensive, so there goes any > potential savings in speed. > > Ideas?
Agreed, it is indeed backward incompatible. However, I think we can make the upgrade for those affected very anyways: * Document this change properly in the release notes and in the testing docs * Document that tests should not depend on hard coded primary key values (this is already hinted in the testing docs where TestCase/TransactionTestCase is described) * Add a reset_sequences attribute on TransactionTestCase, that can be applied to existing TransactionTestCase tests that already uses hard coded primary key value - which will reset sequences *before* the test run, just like before. (And those tests will also flush the database after they are run) I have updated the pull request with the reset_sequences attribute and an initial draft for the release notes and documentation: https://github.com/django/django/pull/45 1.1 introduced a far greater change to testing behavior (the TestCase with transaction/rollback), if that change was considered acceptable from a backward compatibility perspective, this change should be too. When that happened, the same problem appeared since TestCase does not reset sequences. (Yeah, just because it was done in the past does not make it OK now, but that should give some perspective). I guess it boils down to where to draw the line for backward compatibility here. :-) I personally think it is acceptable since we can offer a very easy fix for the existing (already broken) tests out there. Andreas -- 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.
