State of Hedis and TODOs

In order of descending priority.

Github Issues and Pull requests

• Priorities vary
• Some of them overlap with the big-picture issues discussed below.

Redis API Completeness

The idea of Hedis is to support all Redis commands by having one typesafe function per command.

• Commands code generator: The code generator uses the commands.json file from github.com/antirez/redis-doc which is used on the redis.io website.

  • My current state of mind is to completely remove the code generator and implement all commands by hand. Otherwise it has to be support more/all commands.
  • PROs of the code generator
    • Can be sure that all commands exist as Haskell functions
    • Automatic Haddock with one-sentence description and link to Redis documentation website.
    • No errors/mistakes where it works
  • CONs of the code generator
    • It's a mess, partly because commands.json the Redis API is a mess itself.
    • Is not "feature-complete", some commands have/need manual implementations.
    • Does not support optional arguments very well.
    • commands.json does not document all return types -> they need maintenance.

• Optional Arguments Currently has more than one function per Redis command for different optional arguments (e.g. BITOP).

  • Only have one function per command that takes an "optionals" argument. See the OPTS a monoid in redis-resp http://hackage.haskell.org/package/redis-resp-0.3.2/docs/Data-Redis-Command.html#t:Opts for a great solution. (Although it's not quite perfect since it is possible to add conflicting optionals args, e.g. use both XX and NX in the SET command.)
  • Might still be necessary to have multiple functions when optional arguments change the return type (e.g. ZRANGEBYSCORE). Or only allow one return type (e.g. always use ZRANGEBYSCOREWITHSCORES).

• Hedis supports commands up to Redis 2.6.?. The newer commands need implementations (decide on the fate of the code generator first).

• Mapping of Haskell types to Redis types: simplicity and convenience vs. correctness (Some issues and pull requests on this topic).

  1. All containers are Haskell lists (current approach):
  • nice list syntax.
  • easy conversion to all collection types.
  • No real loss of safety for return types
  • can fail for arguments (list vs. non-empty)
  2. "correct" container types for each Redis type:
  • Non-empty lists (unconvenient syntax?)
  • Sets
    • Which set type, Set vs HashSet vs ..
    • Redis already returns "sets" in the sense that each element exists only once in the returned list.
  • Maps
  • etc.

Command Return Types

Currently every command returns the result wrapped in Maybe Reply. This is "what Redis returns" but it's unconvenient to use.

• Return the results "unwrapped" and throw an exception when the reply is an error or can not be decoded to the desired return type.
• Does this work with the Queued return type in Mult/Exec?