Support ByteArrayCodec only for values

[dmandalidis]

Feature Request

I think it would worth the effort to implement a mix of StringCodec and ByteArrayCodec for keys and values respectively. While someone could easily use the ByteArrayCodec and convert the key to string afterwards, this is not possible when the ByteArrayCodec is wrapped inside the CompressionCodec. In that way, one cannot escape from having compressed keys even though the original intention would commonly (IMHO) be to just compress the value.

@mp911de I could give it a try if you feel so. My gut feeling is that, if accepted, a little bit of refactoring would be needed to avoid code duplication between the new one, StringCodec and ByteArrayCodec, but we can have a first version in a PR and discuss on how you 'd suggest to proceed

[mp911de]

Thanks for report. How if we add a codec adapter so we aid codec creation, something like RedisCodec<String, byte[]> codec = RedisCodec.of(StringCodec.UTF8, ByteArrayCodec.INSTANCE)?

[dmandalidis]

Less code duplication indeed, should I proceed implementing it?

[dmandalidis]

On second thought, I think I didn't understand the proposal. I guess you are referring to something like:

// RedisCodecAdapter.java
static <K, V> RedisCodec<K, V> of(RedisCodec<K, V> keyCodec, RedisCodec<K, V> valueCodec);

In that way V type for key codec is useless (like the K type in valueCodec). It seems more correct to create a RedisKeyCodec and a RedisKeyValue codec and have the adapter combine them to create a RedisCodec

[mp911de]

We don’t distinguish between key and value codecs. The of(...) method needs a slight tweak to genetics: key codec would be <K, ?> and value codec <?, V> as we’re combining only the portion of generics what the actual codec is used for.

Feel free to submit a PR. We’ll work out the rest over some code.