This is a small-ish refactoring chore. See #360 (comment)
Currently there is some code duplication between ingestion and serving for the generation and parsing of Redis keys. We multiplied this in the course of implementing Cassandra storage (#360), as it is already a large change set we didn't want to introduce additional Redis refactoring to it and thus decided to log it as a follow-up.
This could be done for Redis independent of and before integrating the Cassandra implementation though, and Cass implementation can be updated to follow the pattern if so.
Update: The below storage modularization was realized through #529 and subsequent PRs that implemented its interfaces. This issue remains for tech debt of code duplication that still remains, enumerated in #402 (comment)
In the interest of storage modularization to minimize dependency headaches in the future (something I believe we'll hash out in further RFC issues), I propose something like this:
1. A storage-api module, which defines an interface something like KeyUtil
1. A storage-redis implementation module which implements KeyUtil for Redis
I'm open to better naming suggestions, structure is more my focus here.
The KeyUtils could ideally be static so that unit testing them is trivially simple and the unit tests can serve as a good spec/documentation of the key format.
This is a small-ish refactoring chore. See #360 (comment)
Currently there is some code duplication between ingestion and serving for the generation and parsing of Redis keys. We multiplied this in the course of implementing Cassandra storage (#360), as it is already a large change set we didn't want to introduce additional Redis refactoring to it and thus decided to log it as a follow-up.
This could be done for Redis independent of and before integrating the Cassandra implementation though, and Cass implementation can be updated to follow the pattern if so.
Update: The below storage modularization was realized through #529 and subsequent PRs that implemented its interfaces. This issue remains for tech debt of code duplication that still remains, enumerated in #402 (comment)
In the interest of storage modularization to minimize dependency headaches in the future (something I believe we'll hash out in further RFC issues), I propose something like this:1. Astorage-apimodule, which defines an interface something likeKeyUtil1. Astorage-redisimplementation module which implementsKeyUtilfor RedisI'm open to better naming suggestions, structure is more my focus here.TheKeyUtils could ideally bestaticso that unit testing them is trivially simple and the unit tests can serve as a good spec/documentation of the key format.