hasura/graphql-engine
1
0
Fork 0
mirror of https://github.com/hasura/graphql-engine.git synced 2024-12-15 17:31:56 +03:00
Code Issues Projects Releases Wiki Activity
d715387e29
graphql-engine/server/forks/hedis/TODO.md
Puru Gupta 328b7b793f server: add support for redis clusters 
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8867
Co-authored-by: paritosh-08 <85472423+paritosh-08@users.noreply.github.com>
GitOrigin-RevId: 6ab173b02f6b8bf97ccbcdb00110fe147771c751
2023-06-05 12:11:59 +00:00

3.0 KiB
Raw Blame History

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?