Skip to content

Latest commit

 

History

History
74 lines (58 loc) · 2.97 KB

TODO.md

File metadata and controls

74 lines (58 loc) · 2.97 KB
Raw

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)
    1. "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?