Will timeouts be considered to adding to the repo? about miniredis HOT 14 CLOSED

The primary use case for miniredis is unittests, in which case timeouts are not wanted. I do want to test if timeouts are set correctly, but the timeouts shouldn't trigger. So I prefer to keep them as is.

What's your use case for the timeouts?

from miniredis.

Thanks for your reply. Currently I'm using Redis to implement a rate-limiting service, and trying to cover all the functionalities by unittests. And till now, only the expire part cannot be covered when using miniredis as a mock. Do you have any suggestions?

from miniredis.

I see you point, I'll think about it. It would certainly be optional behavior.

from miniredis.

Yes, and I'm thinking about adding this feature in my fork, my current idea is to add a periodic timer to trigger key deletion in the DB. How do you like it?

from miniredis.

The more I think about it the more I would make a sort of fast-forward, time-machine function. You call it with a duration, and all TTLs timeouts will be decreased by that much, and any expired keys will be deleted. In this way you then have full control in your tests over how 'fast' time goes. You can do things like:

<set redis keys with ttl of 7 days>
db.FastForward(24 * time.Hour)
<check that things didn't expire yet>
db.FastForward(6 * 24 *time.Hour)
<check that things expired>

Or you can call it in a quick loop in your test, if you want more real-time like behavior. I think having a system which is paused by default and only moves when you tell it to should work good for testing. And as a bonus you won't need to call time.Sleep() in your tests, which keeps them speedy and simple.

Some things to consider:

• The TTL values are currently simple integers, and sometimes they are seconds, and sometimes they are milliseconds. You might want to add another map which keeps things as proper durations
• Redis used to support absolute timestamps as TTLs, maybe that should simply not be supported here?
• Maybe it is nicer to work with absolute times, and not with durations. Not sure.

How about this way, Sun?

from miniredis.

Hi Harmen, I like the idea of time machine, and for mock redis, the time manipulation be as flexible as possible. And If I understand your idea correctly, it should be somewhat like #14 (could you help to review it? Thanks! ).
Furthermore, there should also be a FastForward in miniredis.go, so that when people writing unittest they can call the function and manipulate time as they want.

Regarding your concerns, I think for unit test, durations should work fine. And I agree that TTL values can be extended with units (seconds, milliseconds, etc).

from miniredis.

Looks good as the general idea. Would it be useful this way in the mixer project?

from miniredis.

Thanks, and yes, it is useful for the unit test of our redis-based rate-limiter. And would you like to merge the PR in? If so, I will make it more complete.

from miniredis.

Yeah, I would like to merge it.

from miniredis.

Awesome, I will update the PR, and your comments would be a lot of help.

from miniredis.

I pulled your branch into the ttl branch from #15, and made some more small improvements to the expire handling.

Does this now work for you? If so I'll merge this into master and call it 2.0.

from miniredis.

It's merged, let me know if there are any issues!

from miniredis.

And thanks for the help!

from miniredis.

Yes, it looks great! Thank you!

from miniredis.