Adds HGETDEL Support to Valkey #2851

roshkhatri · 2025-11-17T08:28:56Z

Adds support for HGETDEL to Valkey and aligns with Redis 8.0 feature.
Maintains syntax compatibility
Retrieves all the values, and null if fields dont exists and deletes once retrieved.

127.0.0.1:6379> HGETDEL key FIELDS numfields field [ field ... ]

127.0.0.1:6379> HSET foo field1 bar1 field2 bar2 field3 bar3
(integer) 3
127.0.0.1:6379> HGETDEL foo FIELDS 1 field2
1) "bar2"
127.0.0.1:6379> HGETDEL foo FIELDS 1 field2
1) (nil)
127.0.0.1:6379> HGETALL foo
1) "field1"
2) "bar1"
3) "field3"
4) "bar3"
127.0.0.1:6379>  HGETDEL foo FIELDS 2 field2 field3
1) (nil)
2) "bar3"
127.0.0.1:6379> HGETALL foo
1) "field1"
2) "bar1"
127.0.0.1:6379> HGETDEL foo FIELDS 3 field1 non-exist-field
(error) ERR syntax error
127.0.0.1:6379> HGETDEL foo FIELDS 2 field1 non-exist-field
1) "bar1"
2) (nil)
127.0.0.1:6379> HGETALL foo
(empty array)
127.0.0.1:6379>

Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>

codecov · 2025-11-17T08:55:44Z

Codecov Report

❌ Patch coverage is 96.66667% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 72.41%. Comparing base (9562bdc) to head (809de8d).
⚠️ Report is 1 commits behind head on unstable.

Files with missing lines	Patch %	Lines
src/t_hash.c	96.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           unstable    #2851   +/-   ##
=========================================
  Coverage     72.41%   72.41%           
=========================================
  Files           128      128           
  Lines         70439    70469   +30     
=========================================
+ Hits          51006    51029   +23     
- Misses        19433    19440    +7

Files with missing lines	Coverage Δ
src/commands.def	`100.00% <ø> (ø)`
src/server.h	`100.00% <ø> (ø)`
src/t_hash.c	`96.25% <96.66%> (+0.09%)`	⬆️

... and 14 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

hwware · 2025-11-17T18:07:50Z

@valkey-io/core-team I would like to add this pr to next meeting agenda to discuss more, Thanks

hwware · 2025-11-17T18:09:35Z

I think it is one feature to align with Redis 8

zuiderkwast · 2025-11-17T18:54:12Z

If it's the same syntax as in Redis 8, I vote YES.

roshkhatri · 2025-11-17T19:04:46Z

If it's the same syntax as in Redis 8, I vote YES.

It is not, but I can make it the same

zuiderkwast · 2025-11-17T19:22:45Z

Ah... Redis insist on using this very ugly syntax for all new commands. It appears to be designed for machine generated command lines, not humans.

HGETDEL key FIELDS numfields field [field ...]

I think your syntax HGETDEL key field [field ...] is much nicer. I don't know if Redis compatibility is important or not. Maybe it's best to discuss it in a meeting then.

@valkey-io/client-maintainers WDYT?

roshkhatri · 2025-11-17T19:26:58Z

Yeah, it is the same as HTTL

HTTL key FIELDS numfields field [ field ... ]

https://valkey.io/commands/httl/

The one I implemented is similar to HMGET: HMGET key field [ field ... ]

I think we have similar syntax in valkey as well so it would be generally better to keep compatibility

JimB123 · 2025-11-17T19:41:18Z

I like consistency with HMGET better than creating a weird syntax just to align with Redis.

That said, IF the 3rd parameter is a number AND the number equals the number of remaining parameters, we could just silently ignore it. But, unfortunately, that becomes ambiguous in a case like this: HGETDEL key 3 4 5 6 - is "3" a field? or a count of fields?

hpatro

Regarding the syntax, users migrating from Redis to Valkey will have problems if we don't choose to stick with it. We have decided to stick through with so many of features so far (Hash field expiration / Search / JSON). So, I think we should continue have symmetry with them atleast on the data path commands which were introduced there first.

Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>

nihohit · 2025-11-17T20:07:23Z

Breaking API with Redis will mean that client maintainers might need to choose sides, and only fully support one DB, and offer partial support for the other, which will also lead to poor UX for the client users, since these details are easy to miss, and expectations won't match reality.
Unless there's a clear benefit that's worth the potential harm, I would prefer for valkey to be consistent with Redis where possible (and the other way around too, of course).

roshkhatri · 2025-11-17T20:12:34Z

Updated the top comment and this PR now maintain syntax compatibility.

hwware · 2025-11-17T20:32:19Z

I have one question: In Redis 8.0, it introduces this command HGETDEL, the open source license was changed before Redis 8.0. I am not sure how many users migrating from Redis 8.0 to Valkey? Do we need still align with the Redis weird syntax?

Honestly, I do not like the format: HGETDEL key FIELDS numfields field [field ...]

ranshid

Gave a quick one (and will continue tomorrow)
Looks good overall. I would be happy if we can also include a test in hashexpire.tcl to test the command when there are expired fields.

src/t_hash.c

src/commands/hgetdel.json

ranshid · 2025-11-17T22:29:20Z

I have one question: In Redis 8.0, it introduces this command HGETDEL, the open source license was changed before Redis 8.0. I am not sure how many users migrating from Redis 8.0 to Valkey? Do we need still align with the Redis weird syntax?

Honestly, I do not like the format: HGETDEL key FIELDS numfields field [field ...]

I also do not like the FIELDS (although it has advantages for adding future command arguments), but I agree with the state that we should be more aligned with the client ecosystem needs and I think it is overriding personal taste ATM.

rueian · 2025-11-17T23:11:16Z

As a client maintainer, I suggest aligning with the weird syntax as long as the command name remains the same.

Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>

yangbodong22011 · 2025-11-18T03:10:06Z

I vote for use Redis syntax. (for save time and compatibility, Redis client for Valkey, Valkey client for Redis)

P.S. Actually, client can support both two syntax use two api.

ranshid · 2025-11-18T08:26:33Z

@valkey-io/core-team Let me summarize the decision points:

Should we support this new API? this functionality is already available since Valkey 9.0 (eg HGETEX myhash EX 0 FIELDS ....)
Should we duplicate the Redis API? The majority of comments here suggest we do. This will probably make it easier for client libraries to support it ifor both Redis and Valkey
Order regarding command complexity. When we introduced HFE we decided to set the complexity of variadic commands.
I think O(N) sounds better but in that case we need to take an action item to align other commands (can/should be in a separate PR)
keyspace notifications: Currently the decision is to produce keyspace evenets ONLY when there are actually mutations oin the objects. we will trigger a SINGLE hdel event in case we deleted at least 1 field and del event in case the object was deleted after all fields deleted.

hwware · 2025-11-18T15:58:27Z

If it's the same syntax as in Redis 8, I vote YES.

It is not, but I can make it the same

Now the syntax is same as redis https://redis.io/docs/latest/commands/hgetdel/

ranshid · 2025-11-19T05:51:20Z

@valkey-io/core-team do you want to try and take a decision offline (on this PR) or should I schedule this to be a topic on Monday?
Seems to me it might not require an extensive talk so maybe we can push this by aligning offline?

hwware · 2025-11-19T15:51:05Z

@valkey-io/core-team Let me summarize the decision points:

Should we support this new API? this functionality is already available since Valkey 9.0 (eg HGETEX myhash EX 0 FIELDS ....)

I vote yes, we can have this new command API

Should we duplicate the Redis API? The majority of comments here suggest we do. This will probably make it easier for client libraries to support it ifor both Redis and Valkey

According to above comments from some contributors, it looks like it is better to align with Redis command syntax

Order regarding command complexity. When we introduced HFE we decided to set the complexity of variadic commands.
I think O(N) sounds better but in that case we need to take an action item to align other commands (can/should be in a separate PR)

Yes, O(n) is fine

keyspace notifications: Currently the decision is to produce keyspace evenets ONLY when there are actually mutations oin the objects. we will trigger a SINGLE hdel event in case we deleted at least 1 field and del event in case the object was deleted after all fields deleted.

I agree with this part coding logic.

zuiderkwast · 2025-11-19T20:24:09Z

+1 for Wen's comments. (Yes, align with Redis syntax, O(n), single hdel event.)

ranshid · 2025-11-20T11:14:32Z

+1 for Wen's comments. (Yes, align with Redis syntax, O(n), single hdel event.)

O.K so we have 2 TSC approvers. @zuiderkwast should we still wait for the next meeting or start driving it here? (simply asking: should I remove the majority needed?)

src/t_hash.c

enjoy-binbin · 2025-11-21T03:03:23Z

Also +1 for Wen's comments. (Yes, align with Redis syntax, O(n), single hdel event.)

madolson · 2025-11-24T16:54:06Z

Weekly meeting. This feature is probably OK since compatibility is useful and the cost for this feature is quite low. We would like to have better long term guidance on what features we implement from Redis though.

ranshid · 2025-11-25T06:00:23Z

src/t_hash.c

+
+        /* If hash doesn't exist, continue as already replied with NULL */
+        if (o == NULL) continue;
+        if (hashTypeDelete(o, c->argv[i]->ptr)) {


NOTE: I know that I drove you to implement it this way, but now I thought of a reason why the old way might have been "useful". What should we do in case the same fields is provided multiple times?
For example:

HMSET myhash f1 a f2 b f3 c HGETDEL myhash fields 3 f1 f1 f1

in your previous implementation is would be:

"a", "a", "a"

which is slightly less efficient, but might fits better with common sense.
In the CURRENT implementation it would yield :

"a", nill, nill

BTW - Redis does as as the CURRENT implementation does (which means they return "a", nill, nill)

IMO we are doing the right thing just need to make sure we document it correctly

Can we just place a test for it, so that we know we do not break this in the future?

@valkey-io/core-team I think we are taking the right decision (although maybe common sense would say otherwise), just raising this as an FYI

#2875) When we added the Hash Field Expiration feature in Valkey 9.0, some of the new command docs included complexity description of O(1) even tough they except multiple arguments. (see discussion in #2851 (comment)) This PR does: 1. align all the commands to the same description 2. fix the complexity description of some commands (eg HSETEX and HGETEX) --------- Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

valkey-io#2875) When we added the Hash Field Expiration feature in Valkey 9.0, some of the new command docs included complexity description of O(1) even tough they except multiple arguments. (see discussion in valkey-io#2851 (comment)) This PR does: 1. align all the commands to the same description 2. fix the complexity description of some commands (eg HSETEX and HGETEX) --------- Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

ranshid

LGTM

valkey-io#2875) When we added the Hash Field Expiration feature in Valkey 9.0, some of the new command docs included complexity description of O(1) even tough they except multiple arguments. (see discussion in valkey-io#2851 (comment)) This PR does: 1. align all the commands to the same description 2. fix the complexity description of some commands (eg HSETEX and HGETEX) --------- Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

Fixes this: valkey-io#2850 Adds support for HGETDEL to Valkey and aligns with Redis 8.0 feature. Maintains syntax compatibility Retrieves all the values, and null if fields dont exists and deletes once retrieved. ``` 127.0.0.1:6379> HGETDEL key FIELDS numfields field [ field ... ] ``` ``` 127.0.0.1:6379> HSET foo field1 bar1 field2 bar2 field3 bar3 (integer) 3 127.0.0.1:6379> HGETDEL foo FIELDS 1 field2 1) "bar2" 127.0.0.1:6379> HGETDEL foo FIELDS 1 field2 1) (nil) 127.0.0.1:6379> HGETALL foo 1) "field1" 2) "bar1" 3) "field3" 4) "bar3" 127.0.0.1:6379> HGETDEL foo FIELDS 2 field2 field3 1) (nil) 2) "bar3" 127.0.0.1:6379> HGETALL foo 1) "field1" 2) "bar1" 127.0.0.1:6379> HGETDEL foo FIELDS 3 field1 non-exist-field (error) ERR syntax error 127.0.0.1:6379> HGETDEL foo FIELDS 2 field1 non-exist-field 1) "bar1" 2) (nil) 127.0.0.1:6379> HGETALL foo (empty array) 127.0.0.1:6379> ``` --------- Signed-off-by: Roshan Khatri <rvkhatri@amazon.com> Signed-off-by: Ran Shidlansik <ranshid@amazon.com> Co-authored-by: Ran Shidlansik <ranshid@amazon.com>

valkey-io#2875) When we added the Hash Field Expiration feature in Valkey 9.0, some of the new command docs included complexity description of O(1) even tough they except multiple arguments. (see discussion in valkey-io#2851 (comment)) This PR does: 1. align all the commands to the same description 2. fix the complexity description of some commands (eg HSETEX and HGETEX) --------- Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

Fixes this: valkey-io#2850 Adds support for HGETDEL to Valkey and aligns with Redis 8.0 feature. Maintains syntax compatibility Retrieves all the values, and null if fields dont exists and deletes once retrieved. ``` 127.0.0.1:6379> HGETDEL key FIELDS numfields field [ field ... ] ``` ``` 127.0.0.1:6379> HSET foo field1 bar1 field2 bar2 field3 bar3 (integer) 3 127.0.0.1:6379> HGETDEL foo FIELDS 1 field2 1) "bar2" 127.0.0.1:6379> HGETDEL foo FIELDS 1 field2 1) (nil) 127.0.0.1:6379> HGETALL foo 1) "field1" 2) "bar1" 3) "field3" 4) "bar3" 127.0.0.1:6379> HGETDEL foo FIELDS 2 field2 field3 1) (nil) 2) "bar3" 127.0.0.1:6379> HGETALL foo 1) "field1" 2) "bar1" 127.0.0.1:6379> HGETDEL foo FIELDS 3 field1 non-exist-field (error) ERR syntax error 127.0.0.1:6379> HGETDEL foo FIELDS 2 field1 non-exist-field 1) "bar1" 2) (nil) 127.0.0.1:6379> HGETALL foo (empty array) 127.0.0.1:6379> ``` --------- Signed-off-by: Roshan Khatri <rvkhatri@amazon.com> Signed-off-by: Ran Shidlansik <ranshid@amazon.com> Co-authored-by: Ran Shidlansik <ranshid@amazon.com>

valkey-io#2875) When we added the Hash Field Expiration feature in Valkey 9.0, some of the new command docs included complexity description of O(1) even tough they except multiple arguments. (see discussion in valkey-io#2851 (comment)) This PR does: 1. align all the commands to the same description 2. fix the complexity description of some commands (eg HSETEX and HGETEX) --------- Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

Fixes this: valkey-io#2850 Adds support for HGETDEL to Valkey and aligns with Redis 8.0 feature. Maintains syntax compatibility Retrieves all the values, and null if fields dont exists and deletes once retrieved. ``` 127.0.0.1:6379> HGETDEL key FIELDS numfields field [ field ... ] ``` ``` 127.0.0.1:6379> HSET foo field1 bar1 field2 bar2 field3 bar3 (integer) 3 127.0.0.1:6379> HGETDEL foo FIELDS 1 field2 1) "bar2" 127.0.0.1:6379> HGETDEL foo FIELDS 1 field2 1) (nil) 127.0.0.1:6379> HGETALL foo 1) "field1" 2) "bar1" 3) "field3" 4) "bar3" 127.0.0.1:6379> HGETDEL foo FIELDS 2 field2 field3 1) (nil) 2) "bar3" 127.0.0.1:6379> HGETALL foo 1) "field1" 2) "bar1" 127.0.0.1:6379> HGETDEL foo FIELDS 3 field1 non-exist-field (error) ERR syntax error 127.0.0.1:6379> HGETDEL foo FIELDS 2 field1 non-exist-field 1) "bar1" 2) (nil) 127.0.0.1:6379> HGETALL foo (empty array) 127.0.0.1:6379> ``` --------- Signed-off-by: Roshan Khatri <rvkhatri@amazon.com> Signed-off-by: Ran Shidlansik <ranshid@amazon.com> Co-authored-by: Ran Shidlansik <ranshid@amazon.com>

github-actions bot assigned roshkhatri Nov 17, 2025

Adds HGETDEL Support to Valkey

fddacdb

Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>

roshkhatri force-pushed the hgetdel branch from 98da96e to fddacdb Compare November 17, 2025 08:35

roshkhatri mentioned this pull request Nov 17, 2025

[NEW] HGETDEL support in Valkey #2850

Closed

hwware added the major-decision-pending Major decision pending by TSC team label Nov 17, 2025

hpatro reviewed Nov 17, 2025

View reviewed changes

hpatro requested a review from ranshid November 17, 2025 19:59

roshkhatri added 2 commits November 17, 2025 19:59

Aligns the syntax with redis commands

07e548f

Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>

remove extra blank line

714da0f

Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>

ranshid added needs-doc-pr This change needs to update a documentation page. Remove label once doc PR is open. release-notes This issue should get a line item in the release notes labels Nov 17, 2025

ranshid reviewed Nov 17, 2025

View reviewed changes

src/t_hash.c Outdated Show resolved Hide resolved

src/t_hash.c Outdated Show resolved Hide resolved

src/t_hash.c Outdated Show resolved Hide resolved

src/commands/hgetdel.json Show resolved Hide resolved

optimize loop and address feedback

658054d

Signed-off-by: Roshan Khatri <rvkhatri@amazon.com>

sarthakaggarwal97 reviewed Nov 20, 2025

View reviewed changes

src/t_hash.c Show resolved Hide resolved

zuiderkwast added major-decision-approved Major decision approved by TSC team and removed major-decision-pending Major decision pending by TSC team labels Nov 24, 2025

ranshid reviewed Nov 25, 2025

View reviewed changes

ranshid mentioned this pull request Nov 26, 2025

Align the complexity description for all multi field HFE commands docs #2875

Merged

ranshid added 2 commits November 26, 2025 13:19

Update src/t_hash.c

73cd821

Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

Merge branch 'unstable' into hgetdel

809de8d

Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

ranshid approved these changes Nov 26, 2025

View reviewed changes

ranshid merged commit 56ab3c4 into valkey-io:unstable Nov 26, 2025
56 checks passed

Adds HGETDEL Support to Valkey #2851

Adds HGETDEL Support to Valkey #2851

Conversation

roshkhatri commented Nov 17, 2025 • edited by zuiderkwast Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

hwware commented Nov 17, 2025

Uh oh!

hwware commented Nov 17, 2025

Uh oh!

zuiderkwast commented Nov 17, 2025

Uh oh!

roshkhatri commented Nov 17, 2025

Uh oh!

zuiderkwast commented Nov 17, 2025

Uh oh!

roshkhatri commented Nov 17, 2025

Uh oh!

JimB123 commented Nov 17, 2025

Uh oh!

hpatro left a comment

Choose a reason for hiding this comment

Uh oh!

nihohit commented Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

roshkhatri commented Nov 17, 2025

Uh oh!

hwware commented Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ranshid left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ranshid commented Nov 17, 2025

Uh oh!

rueian commented Nov 17, 2025

Uh oh!

yangbodong22011 commented Nov 18, 2025

Uh oh!

ranshid commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hwware commented Nov 18, 2025

Uh oh!

ranshid commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hwware commented Nov 19, 2025

Uh oh!

zuiderkwast commented Nov 19, 2025

Uh oh!

ranshid commented Nov 20, 2025

Uh oh!

Uh oh!

enjoy-binbin commented Nov 21, 2025

Uh oh!

madolson commented Nov 24, 2025

Uh oh!

ranshid Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ranshid Nov 25, 2025

Choose a reason for hiding this comment

Uh oh!

ranshid Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ranshid left a comment

Choose a reason for hiding this comment

roshkhatri commented Nov 17, 2025 •

edited by zuiderkwast

Loading

codecov bot commented Nov 17, 2025 •

edited

Loading

nihohit commented Nov 17, 2025 •

edited

Loading

hwware commented Nov 17, 2025 •

edited

Loading

ranshid commented Nov 18, 2025 •

edited

Loading

ranshid commented Nov 19, 2025 •

edited

Loading

ranshid Nov 25, 2025 •

edited

Loading

ranshid Nov 25, 2025 •

edited

Loading