Hacker News new | ask | show | jobs
by andydunstall 1606 days ago
Hey, I'm the author of this blog post. Ask me anything!
2 comments

I don't want to sound snarky, but since you mentioned that Redis does not document if/that "multiple key expiry is guaranteed to occur at the same time if keys have the same EXPIREAT setting", I am tempted to ask - why did you not check the implementation you're using? That's the unique selling point of using FOSS - you don't have rely on documentation or observational guesswork - you can wade in and really see for yourself! Redis' source code is especially readable in my opinion (thanks again, antirez, for creating this little load-bearing gem of a data structure server), so I would very much encourage you to try, even if C is not your particular forte :)
Not who you're asking but... why have documentation at all? So that we don't have to read source code.
Because documentation is what is needs to be: A simplified and necessarily incomplete description of program behavior. It's a trade-off, since a complete and exhaustive description of all intricacies of potential program behavior would be at least as complex as the definition (= its source code) of said program.

If you happen to have a question that ends up on the wrong side of that trade-off between documentation's completeness and accessibility, you will have to descend into the depths that lie beneath. I believe the redis documentation actually strikes a rather OK balance in that regard.

Good docs generally make guarantees and pitfalls clear.
Of course having documentation is better but that's not a reason not to read the source code if the documentation isn't enough.
Because good docs are like a good search engine: high hit rate for what you want most of the time.

The edge cases and quirky impl detail questions are what src is for.

I would argue that outlining expected behaviour in edge cases is one of the most important topics for documentation to cover.
> The edge cases and quirky impl detail questions are what src is for.

Literally the most important thing you can document.

You can’t cover every usage possibility in docs… having the code available allows you to check expected behaviour
You also can’t tell what is supported behavior and what is implementation coincidence from the code…
That's a great suggestion, and OP should do this, but even if OP verifies behaviour today through code inspection, it's possible a future release could change it. The problem is that Redis doesn't want to make that guarantee so you can't rely on it.
yep good point :) - in the end it didnt matter much as we could maintain our invariants if we just reordered the expires
Would Redis Keyspace Notifications [1] help in this case? Like a script that runs when a specific key expires, such that all other related keys can be deleted too.

[1] https://redis.io/topics/notifications

these notifications aren't guaranteed to fire at the expire time, wouldn't that be same as current problem?
thanks for pointing that out - will take a look :)