Skip to content

Latest commit

 

History

History
57 lines (42 loc) · 2.06 KB

TODO.md

File metadata and controls

57 lines (42 loc) · 2.06 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.

  • 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.

  • 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?