Skip to content

DATAREDIS-698 - Add support for HSTRLEN. #283

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

Closed
wants to merge 3 commits into from

Conversation

christophstrobl
Copy link
Member

We now support HSTRLEN command throughout RedisHashCommand for Lettuce and Jedis in both an imperative and reactive (Lettuce only) manner.

However as Jedis does not natively support HSTRLEN via its API we’ve come up with some more reflective invocation allowing to execute commands currently not known by Jedis. We also added this behavior to the cluster implementation which as of now also supports RedisClusterConnection#execute.

christophstrobl and others added 3 commits October 3, 2017 09:59
We now support HSTRLEN command throughout RedisHashCommand for Lettuce and Jedis in both an imperative and reactive manner.

However, Jedis not natively supporting HSTRLEN via its API we’ve come up with some more reflective invocation allowing to execute commands currently not known by Jedis. We also added this behavior to the cluster implementation which as of now also supports RedisClusterConnection#execute.
Eagerly initialize known commands. Preallocate Jedis response builder. Replace list concatenation with array copy. Reject null arguments in execute() Remove inversion through collections with direct byte array creation. Reorder signatures, visibility modifiers, Javadoc.
@mp911de mp911de force-pushed the issue/DATAREDIS-698 branch from ba3ff9f to be3d937 Compare October 10, 2017 08:32
mp911de pushed a commit that referenced this pull request Oct 10, 2017
We now support HSTRLEN command throug RedisHashCommands for Lettuce and Jedis in both an imperative and reactive manner.

However, Jedis not natively supporting HSTRLEN via its API we’ve come up with some more reflective invocation allowing to execute commands currently not known by Jedis. We also added this behavior to the cluster implementation which as of now also supports RedisClusterConnection#execute.

Original pull request: #283.
mp911de added a commit that referenced this pull request Oct 10, 2017
Eagerly initialize known commands. Preallocate Jedis response builder. Replace list concatenation with array copy. Reject null arguments in execute(). Remove inversion through collections with direct byte array creation. Reorder arguments in signatures, visibility modifiers, Javadoc.

Original pull request: #283.
@mp911de
Copy link
Member

mp911de commented Oct 10, 2017

That's merged now.

@mp911de mp911de closed this Oct 10, 2017
@mp911de mp911de deleted the issue/DATAREDIS-698 branch October 10, 2017 09:28
Assert.notNull(args, "Args must not be null!");

return clusterCommandExecutor
.executeCommandOnArbitraryNode((JedisClusterCommandCallback<Object>) client -> JedisClientUtils.execute(command,
Copy link
Contributor

@pavel-hp pavel-hp Jun 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello! @christophstrobl
I have a question. Why you have chosen executeCommandOnArbitraryNode?
What If someone decided to use this API to run another command like:
connection.execute("FLUSHDB", "ASYNC".getBytes("UTF-8"));
Don't you think that in this case execution behaviour would be different?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants