Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate on codec reconfiguration for a active connection #632

Open
Tracked by #2924
mp911de opened this issue Oct 19, 2017 · 6 comments
Open
Tracked by #2924

Investigate on codec reconfiguration for a active connection #632

mp911de opened this issue Oct 19, 2017 · 6 comments
Labels
for: team-attention An issue we need to discuss as a team to make progress type: task A general task
Milestone

Comments

@mp911de
Copy link
Collaborator

mp911de commented Oct 19, 2017

Using different codecs requires to run multiple connections as each connection is typed with a specific codec. We should investigate whether it's possible to retype a connection to create a new connection facade that provides its functionality with a different codec:

StatefulRedisConnection<String, String> connection  = …

StatefulRedisConnection<byte[], byte[]> binary = connection.withCodec(ByteArrayCodec.INSTANCE);
@mp911de mp911de added for: team-attention An issue we need to discuss as a team to make progress type: task A general task labels Jun 16, 2018
@TheSpiritXIII
Copy link

I agree with this suggestion. My use case is this: I want to reuse a connection pool but serialize differently depending on the data structure, e.g. single Redis database but with maps and lists used for different purposes.

While I agree this depends largely on the serialization strategy (deserializing between different key types may be tricky and lead to ill effects), the user should decide whether they want to. In most cases, e.g. when my serialization strategy is JSON/XML/etc, it is valid.

I could do this in Spring Data Redis via RedisTemplate<K, V>. There, I could have different templates with different serialization strategies utilizing the same connection factory. We could look through what Spring has done, because they have a slightly better API for this (however, I opted to use Lettuce because they have an asynchronous API, while Spring does not).

@mp911de mp911de added this to the Backlog milestone Aug 16, 2018
@mp911de
Copy link
Collaborator Author

mp911de commented Aug 25, 2018

Looking at the API, we could introduce StatefulRedisConnection.withCodec(…) to create a new object that exposes sync/async/reactive API objects that are associated with the new RedisCodec. The thing here is that StatefulRedisConnection isn't the right type to return as we would have two connection object instances whereas we have only a single connection. Finding a good name for the type seems the actual challenge here.

@TheSpiritXIII You could create RedisAsyncCommandsImpl instances passing in the connection object and a RedisCodec to create multiple async API facades for a single connection.

Another caveat is that RedisAsyncCommandsImpl and other command API types return StatefulRedisConnection.

@osoriano
Copy link

osoriano commented Oct 15, 2018

I'm migrating from Jedis and hitting this issue as well. Jedis supports byte[]/String methods out of the box (edit: on the same connection), but for Lettuce, I'm planning to use a RedisCodec<ByteBuffer,ByteBuffer> and manually encode/decode the Lettuce calls.

@mp911de
Copy link
Collaborator Author

mp911de commented Oct 16, 2018

Lettuce supports binary and String types out of the box (ByteArrayCodec.INSTANCE, StringCodec.UTF8, StringCodec.ASCII).

@little-fish
Copy link

Hello.
Is there any progress related to this feature?
Thank you.

@mp911de
Copy link
Collaborator Author

mp911de commented Jul 28, 2020

Right now, there's no proper way how to achieve this functionality.

We either get hold of another connection object that doesn't represent the actual connection or we get a back-reference to a connection that isn't using the reconfigured codec (RedisCommands.getStatefulConnection()).

That being said, if you have another proposal, we're happy to discuss it here.

@tishun tishun added status: good-first-issue An issue that can only be worked on by brand new contributors for: team-attention An issue we need to discuss as a team to make progress and removed for: team-attention An issue we need to discuss as a team to make progress status: good-first-issue An issue that can only be worked on by brand new contributors labels Jul 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: team-attention An issue we need to discuss as a team to make progress type: task A general task
Projects
None yet
Development

No branches or pull requests

5 participants