Skip to content

Using RedisTemplate executePipelined, rightPushAll and lRange behavior #3123

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
gary258796 opened this issue Mar 21, 2025 · 3 comments
Closed

Comments

@gary258796
Copy link

I'm using rightPushAll inside executePipelined like below to put List data into redis list,


        List<Row> rows = getRows();

        redisTemplate.executePipelined(new SessionCallback<Object>() {

            @Override
            public <K, V> Object execute(RedisOperations<K, V> operations) throws DataAccessException {

                RedisOperations<String, Row> customOps = (RedisOperations<String, Row>) operations;

                customOps.opsForList().rightPushAll(kxy, rows);

                customOps.expire(kxy, taskCacheExpireDuration);

                return null;

            }

        }, redisTemplate.getDefaultSerializer());

And for the code using range to get list data from redis


        RedisSerializer<String> kxySerializer = (RedisSerializer<String>) redisTemplate.getKeySerializer();

        List<Object> rows = redisTemplate.executePipelined((RedisCallback<List<Object>>) connection -> {

            connection.listCommands().lRange(kxySerializer.serialize(kxy), startIndex, endIndex - 1);

            return null;

        });

        if (CollectionUtils.isEmpty(rows)) {
            return Collections.emptyList();
        }

        return (List<DataGridRow>) rows.get(0);

The above code work nicely, but i notice that instead of storing the elements individually as List<Object, Object, Object, ...>, Redis stored the entire list as a single element, resulting in List<List>.

I ran some tests and confirmed that whether I use executePipelined or not, the command rightPushAll(kxy, rows) produces the same result. However, if I use rightPushAll(kxy, rows.toArray()), the result turns out as expected, something like List<Object, Object, Object, ...>.

Additionally, when retrieving data from the list using range without executePipelined, it fails to fetch the data correctly. But with executePipelined, it retrieves the data as expected. Since all the inserted data is stored within a single element, the retrieved data structure is List<List>.

Is the above behavior expected, or did I make a mistake in how I used it?

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Mar 21, 2025
@mp911de
Copy link
Member

mp911de commented Mar 21, 2025

leftPushAll and rightPushAll provide overloaded variants accepting either varargs or Collection<T>. When your input type encounters a mismatch to Collection<T> then you might accidentally use varargs without actually noticing it. Please recheck that you're ending up using the correct method.

If you still encounter the same problem, please provide a minimal yet complete sample that reproduces the problem.
You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

@mp911de mp911de added the status: waiting-for-feedback We need additional information before we can continue label Mar 21, 2025
@spring-projects-issues
Copy link

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

@spring-projects-issues spring-projects-issues added the status: feedback-reminder We've sent a reminder that we need additional information before we can continue label Mar 28, 2025
@spring-projects-issues
Copy link

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

@spring-projects-issues spring-projects-issues closed this as not planned Won't fix, can't repro, duplicate, stale Apr 4, 2025
@spring-projects-issues spring-projects-issues removed status: waiting-for-feedback We need additional information before we can continue status: feedback-reminder We've sent a reminder that we need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged labels Apr 4, 2025
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

No branches or pull requests

3 participants