On May 5, 4:31 pm, Andreas Pelme <andr...@pelme.se> 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.
I would like to just get rid of the sequence resets. Oracle doesn't do it currently, TestCase doesn't do it, and IMO assuming the IDs are going to start from 1 is an assumption one should not make. Objections to just getting rid of the sequence resets altogether (with the opt-in flag)? - Anssi -- 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.
