Support reset_sequences

[cb109]

This adds support for using the reset_sequences feature of Django's TransactionTestCase.

It will try to reset all automatic increment values before test execution, if the database supports it. This is useful for when you have tests that rely on such values, like ids or other primary keys.

• Use as a mark option:

@pytest.mark.django_db(transaction=True, reset_sequences=True)
def test_something():
    pass

• Use as a fixture:

@pytest.fixture
def setup(reset_sequences_db):
    pass

Please let me know your thoughts.

[blueyed]

s/mark.django_db/mark.reset_sequences_db/

[cb109]

I am sorry, I don't understand 😕 Is that sphinx syntax?

[blueyed]

No, sed.. ;)
Change "mark.django_db" to "mark.reset_sequences_db".

It seems you have copied it from the paragraph above, but it should be changed here - if I understand it correctly.

[cb109]

Ahh okay 😌 ! There is only one marker (django_db), but it has some optional keywords that make the difference. I updated that section of the docs to make it clear which one to use for a test to get the same effect as using the fixture.

[blueyed]

Awesome, thanks!

[cb109]

Thanks for your review @blueyed 🙇 !

[das-g]

Any news on this?

[pelme]

Thanks for the PR! It mostly looks good and this would be a very useful feature.

A couple of notes/things that I think should be changed before merge:

This PR changes the return value of db and transactional_db to return the Django TestCase instance that is used internally. I don't think this is the right thing to do - you ask for the db fixture and you get a testcase instance - it does not make sense to me. I guess this is done to be able to test this. However, I think this can be tested with a test that calls runpytest, that just creates a bunch of Item objects and look at their pk to make sure they start at 1.

[cb109]

Hi Andreas, you are probably right about me taking a nasty shortcut there 😊 I will look into it and try to resolve it as you proposed. Thanks for the review 🙇

[blueyed]

@cb109
Great. I've just created #353 (from #331 - serialized_rollback feature) and noticed that they touch the same code. Do you plan to work on this today/tomorrow?
@pelme and me are at the pytest sprint together and would be glad to help out with getting this merged.

[cb109]

I might find time to work at this tomorrow, but not sure. If you want to do it yourself, please go ahead! I hope you enjoy the sprint guys, give a shout to @hackebrot for me please 😄

[hackebrot]

@cb109 💩

[cb109]

👊 😆

[pelme]

@cb109 feel free to continue working in this, it would for sure be a useful feature! :)

[cb109]

I refactored the test to use runpytest and check actual database ids instead of internal pytest-django values. That test should be skipped for databases that do not support it (like sqlite3). I had some issues getting postgresql green with this, but it now is on my machine. Would like to see what the big testsuite on travis says @pelme is there anything I must do to trigger it or will it just test the commits at some later point?

[pelme]

@cb109 Thanks for keeping up the work in this PR!

I think the Travis builds have not been run because automatic merge with master failed -- can you try to merge with the latest master and push again to the PR and see if it gets picked up?

I think the fixture should be renamed to django_db_reset_sequences. In the upcoming release I plan to rename and deprecate the old fixture names (but still keep the old names for compatibility for quite a while) to make it more uniform, i.e. we will have
db -> django_db, transactional_db -> django_db_transactional and then we will have django_db_reset_sequences and django_db_serialized_rollback (PR #331).

[cb109]

@pelme Alright I will rename it once travis is green. It is weird to see some postgresql configurations succeed and others fail, no idea yet what the problem is.

[cb109]

Well, being honest with myself I will probably not get back to this, so let's close it off to not be a burden for you guys. As far as I remember some travis tests where failing and I couldn't figure out why, while the actual feature seemed only supported by very few database setups on top.

I have since come to write tests to not rely on ids at all, which I guess is good practice anyway, so there isn't much motivation left to finish this off. Sorry and thanks for your help on this nonetheless!