Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Transaction commands support #86
The old way of
My implementation is:
Some specs codes are referenced from mock-redis.
Hey, this is most certainly an interesting bug & fix. Thanks for putting this together! I certainly like the fact we're queueing up the commands to run rather than running them and then not being able to discard changes. (Also hadn't noticed
However, I'm not sold on the implementation looking at the diff. It's a novel approach creating method alias' on the fly, but I'm not convinced it's the right thing to be doing here. Especially as we then "revert" the aliases to get out of a multi command (be it via discard or exec). Feels wrong to be using the runtime in this way, if it was a one-off alias of everything it might be acceptable but I think there's other ways to solve this within the ruby toolkit before reaching runtime swizzling.
Almost feels more like something akin to middleware would be a better approach here to me. So it can decide whether to queue the command, or call it immediately and the command definitions are still unaware of whether they're in a multi block or not. (I agree with your implementation in that it doesn't require changes to all the existing command methods!)
So more along the existing
I just tried spiking this up, albeit without running it against your amended specs for multi/discard, and it feels nicer than alias' swizzling to me - https://github.com/guilleiguaran/fakeredis/compare/spike;multi-queue-commands. What do you think? Worth pursuing?
I'm sailing through the scottish highlands with limited internet access and
On 27 May 2014, at 08:58, Larry Lv email@example.com wrote:
Seems like fakeredis is failing with rspec 3.0. Should we lock the rspec version on master?