DSL complete?
ioquatix opened this issue · 20 comments
I merged the DSL branch into master.
Is there more that should be implemented?
would love to see the streams (XADD, XRANGE,XGROUP, etc) commands implemented. I've been testing that out and was able to run most of that with plain calls but I'd love to see a proper implementation.
@aemadrid Can you show me how you used them? Just so I see what the API should look like.
I actually didn't write any spec for bitcount.
@ioquatix There is loads more to be implemented, I'm about a quarter of the way through. Mostly it's just simple as wrapping the call function into convenient methods, sometimes a bit of logic is required to make the methods work nicely. I'm basically just systematically going over the groups and implementing everything from the redis protocol spec.
The way it's organized is that each module contains the redis commands from the corresponding groups, the groupings somehow reflect what the commands operate on.
Edit: with that said some of the groups don't make sense in all contexts like the ones related to pub/sub. Which is why it's nice to separate them out like so.
That makes sense.
Maybe we can generate the methods from the documentation?
Maybe we can generate the methods from the documentation?
Hmm, I suppose there is no reason why something like XADD key ID field string [field string ...] couldn't be parsed and turned into a ruby method. Just need to extract that from the DOM, but that looks easy enough.
Is there something better, e.g. XML from the Redis source code or something?
That looks perfect. We could make a task to update the method stubs from that. It could generate the documentation too.
I suppose the next question is whether or not we want to make the DSL methods more convenient like I did with SET.
I think in the first instance we should just try to generate everything automatically. We could add convenience methods on top some how, or augment the automatically generated version.
Hmm, putting wrappers on top of wrappers sounds like a terrible idea. We could have maybe a Methods::StringsAuto module that gets included alongside the Methods::Strings module. The latter having the augmented methods and the tool we used to automatically generate the methods would skip generating the ones that appear in the module with the augmented methods.
Yeah, anything is possible at this point. I'd just focus on auto-generation for now.
I suppose we still want git to track the auto-generated stuff.
Righto, I had a look at generating the DSL f9faced. That's right a thousand lines of pure awesomeness. It's not doing a very smart job at the moment, it creates variadic methods that simply wrap call. Of course it'll need to do better, but the arguments descriptions in that JSON file are edge case hell.
If worst comes to worst this could just be used to generate all the method and then fill in the blanks manually.
That's awesome.
We moved all of this into protocol-redis.
The DSL is non-trivial but I think we've exposed most of the useful parts.
The next step is to expose some useful high-level data structures, but it makes sense to do this using the DSL, e.g.
class Queue
def initialize(context, key)
@context = context
@key = key
end
def pop
@context.lpop @key
end
endTo me this is the most useful approach.