Re: aedis review starts today

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2023-01-18 18:03:34

As Marcelo pointed out, I did not Reply All; here is the email:

On Tue, Jan 17, 2023 at 3:40 PM Zach Laine <whatwasthataddress_at_[hidden]> wrote:
>
> On Tue, Jan 17, 2023 at 3:11 PM Marcelo Zimbres Silva
> <mzimbres_at_[hidden]> wrote:
> >
> > On Tue, 17 Jan 2023 at 20:39, Zach Laine via Boost
> > <boost_at_[hidden]> wrote:
> > >
> > > No.  In particular, the API requires the user to write lots of Redis
> > > strings by hand.  A typo will not be detected until runtime.  The
> > > set of Redis keywords is fixed; there's no reason not to make an
> > > enumeration of them all, like this:
> >
> > I had enums in the past but I had to remove them for a couple of reasons
> >
> > 1. There are a multitude of possible commands in the Redis stack, for example
> >
> > * Redis search: https://redis.io/commands/?group=search
> > * Redis graph: https://redis.io/commands/?group=graph
> > * Redis time series: https://redis.io/commands/?group=timeseries
> > * Redis json: https://redis.io/commands/?group=json
> > * Perhaps more I might be missing righ now.
>
> I don't yet see the problem.  In the enumeration I made, there's a
> JSON_DEBUG (JSON.DEBUG from https://redis.io/commands/?group=json, but
> with s/./_/), etc.  None of these enumerators collides with any other;
> I compiled the resulting enumeration to check exactly this.  Am I
> missing something?
>
> > Then, we would probably agree that the command syntax is equally
> > important. To check it properly I would have to write a generator that
> > parses the description of each command and generates a checker, see
> > https://github.com/redis/redis/tree/unstable/src/commands.
> >
> > I have made no thoughts so far about how that would work and if I get
> > that correctly I would still have to watch for versioning (what
> > changes from release to release), what new commands were implemented
> > and which were deprecated.
>
> Yep.  That's the job.  The good news is that a new version need not be
> that disruptive.  You only ever need to add to the enumeration, and
> you can add a single deprecation-detection function that compares any
> enumerator used against the list of enumerators that are deprecated.
>
> > That might be enough for Redis, but them I would be keeping other
> > Redis-like databases off, for example
> >
> > * https://github.com/Snapchat/KeyDB
> > * https://github.com/scylladb/scylladb/blob/master/docs/dev/redis.md
> > * https://github.com/dragonflydb/dragonfly
> > * Perhaps more.
> >
> > I don't know how compatible they are with the Redis API. I can't
> > afford working on this right now and in the foreseeable future, I see
> > it almost as a second library of a module of my library e.g.
> > aedis::redis::search::request or something.
>
> Ok, this is something different.  If you don't want to break support
> for those other DBs, that's understandable.  But since you don't have
> support for them at the moment, I don't think possibly adding support
> for those later (which could also be added in much the same way)
> should slow down adoption of a better interface for Redis today.
>
> Zach