Issue #8 resolved

Option to disable timers

Alan Descoins avatarAlan Descoins created an issue

Version 0.4.0 introduced timers when creating/updating/deleting DynamoDB tables, which is great for it to be more realistic.

But sometimes during unit tests I just want creation/deletion of tables to be instantaneous... Django flushes the relational DB after each test, so I would like to do the same thing with various tests that involve DynamoDB.

So, it would be great to have a setting through which I could disable the timers introduced in 0.4.0 :)

Thanks!

Comments (5)

  1. Jean-Tiare Le Bigot

    Thanks for the feedback,

    Just to clarify Timers' role, they are mostly cosmetic in the sense that they only change the "Status" field. The table is immediately ready. The delete timer is a bit different and indeed delays table deletion and I need to add more safety on this side...

    I'm afraid that adding an option dedicated to disabling the timers would unnecessarily clutter the code. But I'll consider it.

    In the mean time, Could you try the same approch as the ddbmock's unit tests ? https://bitbucket.org/Ludia/dynamodb-mock/src/ba37a000ec259d80a75f7a157f3a7cfd9410e4f5/tests/init.py?at=default

    I apologize, I've not yet documented it, but there is a "hard_reset" in the database code specially written for testing environments. Feel free to use it, this part of the API is pretty mature now.

    You may see this setup method as a usage example: https://bitbucket.org/Ludia/dynamodb-mock/src/ba37a000ec25/tests/functional/boto/test_get_item.py

    Does it help ?

  2. Alan Descoins

    The hard_reset is definitely useful! Perfect for unit tests indeed.

    The timer issue still holds but is minor now that the state can be reset without deleting each particular table and waiting.

    Thanks for the quick response!

  3. Jean-Tiare Le Bigot

    I added config.ENABLE_DELAYS option to do what you suggested as, I believe, this is going to be an issue for more people. Nonetheless, this will have side effects. As table.status will be updated immediately. If your code expects a table to first go through 'CREATING' status, for example, then you are in trouble.

    Moreover, If your tests needs some time to do checks on the database side after a delete, they will be broken as the table will be gone.

    To get a better feeling of the impact, you can run ddbmock tests suite with this option disabled.

    Anyway, the internal delete table logic is now much more robust and you could sefely, if ever needed, del dynamodb.data[TABLE_NAME] manually to de-reference a Table without the timer interfering with any new table.

    Thanks again for your feedback, I greatly appreciate !

  4. Alan Descoins

    Great work! Thanks very much for implementing this.

    For simple unit tests (only checking that correct data was saved in DynamoDB tables), like I am doing, it's very useful!

  5. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.