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

Introduce Hash Field Expiration to the Spring Data Redis framework #3054

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

tishun
Copy link

@tishun tishun commented Nov 25, 2024

This change introduces the Hash Field Expiration feature as part of the features provided by the spring-data-redis project.

As part of the change the following commands would be made available:

  • HEXPIRE - expire a set of hash fields after a specified time, measured in seconds
  • HPEXPIRE - expire a set of hash fields after a specified time, measured in milliseconds
  • HEXPIREAT - expire a set of hash fields at a specified UNIX time, measured in seconds since Unix epoch
  • HPEXPIREAT - expire a set of hash fields at a specified UNIX time, measured in milliseconds since Unix epoch
  • HEXPIRETIME (omitted on the grounds it is missing for keys too)
  • HPERSIST - persist a field that was previously marked for expiration
  • HTTL - return the time-to-live of a given hash field in seconds
  • HPTTL - return the time-to-live of a given hash field in milliseconds

The new commands are available as part of the following interfaces:
(based on similar PR #283)

  • RedisHashCommands
  • HashOperations / BoundHashOperations
  • ReactiveHashOperations
  • StringRedisConnection

This feature is available starting from Redis CE version 7.4.x and later

For more information on HFE you can also check out ...
... the blog article on the topic.
... examples of how one can take advantage of the feature in their application


  • You have read the Spring Data contribution guidelines.
  • You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
  • You submit test cases (unit or integration tests) that back your changes.
  • You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

@pivotal-cla
Copy link

@tishun Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

@leonovdmitry
Copy link

hi @tishun !

Is it any updates about your PR? i guess it`s wating for you to take action?

@tishun
Copy link
Author

tishun commented Jan 10, 2025

hi @tishun !

Is it any updates about your PR? i guess it`s wating for you to take action?

Hey @leonovdmitry ,
Happy to see there is some interest in the change.

The current agreement with the Pivotal team is for them to try and review and push this change with the 3.5 release. Mid-January was a tentative and nonbinding ETA that I hope we will be able to meet to start work on approving this.

In the mean time if you feel there are use cases that we've missed please let me know.

I have a follow-up commit for the RedisMap that I hope to push today or tomorrow.

@leonovdmitry
Copy link

hi @tishun !
Is it any updates about your PR? i guess it`s wating for you to take action?

Hey @leonovdmitry , Happy to see there is some interest in the change.

The current agreement with the Pivotal team is for them to try and review and push this change with the 3.5 release. Mid-January was a tentative and nonbinding ETA that I hope we will be able to meet to start work on approving this.

In the mean time if you feel there are use cases that we've missed please let me know.

I have a follow-up commit for the RedisMap that I hope to push today or tomorrow.

@tishun thank you for feedback, yep, i was a bit surprised not to find this function in the current library version, but happy to see PR, so thanks for your work.

About use cases, I don't know if this could be part of the core, but it would be convenient to have a method for get/set ttl for only one field with the result in the form of a response code(Long) and not a list of codes(List)

Good luck and have a nice day!

Copy link
Member

@mp911de mp911de left a comment

Choose a reason for hiding this comment

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

Thanks for your pull request. There are some minor things to be updated. Can you please squash your commits and force-push these along with a DCO sign-off in the commit message?

* @return a {@link Mono} emitting the expiration result - {@code 2} indicating the specific field is deleted
* already due to expiration, or provided expiry interval is 0; {@code 1} indicating expiration time is set/updated;
* {@code 0} indicating the expiration time is not set (a provided NX | XX | GT | LT condition is not met);
* {@code -2} indicating there is no such field; {@literal null} when used in pipeline / transaction.
Copy link
Member

Choose a reason for hiding this comment

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

null when pipelining/transaction in progress doesn't apply to reactive commands as we do not have dedicated pipelining nor transaction support. See also other commands as well.

* @author Christoph Strobl
* @author Tihomir Mateev
*/
class KeyFieldsCommand extends KeyCommand {
Copy link
Member

Choose a reason for hiding this comment

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

HashFieldsCommand fits better the purpose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-triage An issue we've not yet triaged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants