Making command structs digestable #2716
Conversation
There was a problem hiding this comment.
This is neat.
But I've noticed that this approach is leading to a proliferation of files directly in the root of the redis package.
Don't you think as the project grows, having a cluttered root directory can make it harder to manage and make modifications?
Can we eventually just have sub-directories for these perhaps
@chayim
|
And in that case, do you think we should also have the test files in this manner for each of the family of command structs? @chayim |
|
100% agree on sub directories. I FULLY FULLY agree that longer term we should pull everything out into a sub package. That's why this is phase one. I didn't move tests around for this reason.. As we should also move the various parsers (that's what started this). IMHO for a first phase - and maybe someone (@ofekshenawa @SoulPancake ) picking it up... I hope to provide direction. I don't want to do a massive set of changes here as a single PR. Surgical changes! Fair? |
| ClusterCmdable | ||
| ScriptingFunctionsCmdable | ||
| StringCmdable | ||
| PubSubCmdable | ||
| GearsCmdable | ||
| ProbabilisticCmdable | ||
| TimeseriesCmdable |
There was a problem hiding this comment.
Did you guys intend to omit StreamCmdable from this list?
There was a problem hiding this comment.
This is a significant breaking change without StreamCmdable available
There was a problem hiding this comment.
@chayim Can you verify if this was intentional? If not, I think we need an urgent new point release including it. If it was intentional, it should be added to the release notes with workaround / migration instructions. Thanks in advance!
There was a problem hiding this comment.
looks like there's a PR in flight to fix this #2725
There was a problem hiding this comment.
BitMapCmdable is also missing.
PR to fix -> #2737
The Cmdable interface (and files) are far too large to digest. This is a first step towards making these pieces easier to modify. Commands have been grouped like other clients and the command reference.
I think a reasonable second step would be to separate these interfaces into an internal package, and add a layer of abstraction. But this is for contributor ergonomics, not necessarily user facing value.
Cmdable has been split up into a series of files whose suffix is command and a new Cmdable interface added per group - extending Cmdable. For example ACL commands have been moved to acl_commands.go and AclCmdable added to the Cmdable interface.