Skip to content

Draft: Early draft of Key/Channel name prefix namespacing

Peter Adams requested to merge PeterAdams-A/RediStack:namespace2 into master

Motivation

As discussed in issue 94 (https://gitlab.com/Mordil/RediStack/-/issues/94) it would be useful to be able to apply a common prefix to keys and channels as a form of namespacing. I’ve tried drafting how this could be added to commands.

This draft obviously lacks some tests and comments it should have but I would welcome an early opinion on it. It feels a little untidy to me and relatively invasive but I don’t see really obvious ways to make it dramatically better.

Let me know what you think and if it’s heading in the right direction.

Modifications

I’ve tried to change the API as little as possible but the change is quite wide reaching. I think the major cause of change being breaking is changing the type of RedisCommand.arguments. There is probably scope for having less of this change public.

To summarise the changes -

  1. Created a new type for arguments (protocol CommandComponent) - there are 5 implementations which each hold one of
    1. A key
    2. A channel
    3. A match (regex style pattern) for a key
    4. A match for a channel
    5. Any other value
  2. RedisCommand now takes these CommandComponents instead of RESPValues for arguments.
  3. Implement a new RedisNamespacingConnection, wrapping an existing connection, which overrides subscription related methods and send to change the first 4 CommandComponent types by adding a namespace before sending.
  4. A few commands return Keys and Channels - the reverse mapping needs to be applied in the result transform function. To do this I needed to change the type of the result mapping transform to take a namespace as a second input. The commands also needed to change to understand this in their transform. This is obviously asymmetric with the output transform which can be done separate from the command as type information is available for output and the set of types is known and small.
  5. I’ve added a scattering of tests at this time - mostly focusing on the various special return types.

Obvious things missing are.

  1. Integration with connection pool.
  2. More testing
  3. Comments and documentation.
  4. Any sort of performance validation.

Result

When complete you will be able to have a connection type which modifies all commands to add a

Checklist

  • Copyright headers in new files (see CONTRIBUTING.md)
  • Unit tests added
  • API Documentation comments

Merge request reports