Node-redis: how to set expire time

Please check the commands dcoumentation. Every part has it's own parameter so you would write something like:

client.set(key, value, 'EX', 60 * 60 * 24, callback);

Thanks

@BridgeAR the documentation link not working

it doesn't work.. redis version 3.0

client.set(key, value, 'EX', 60 * 60 * 24, callback);

@sxyjijiji it works perfectly fine for me. If you run into an error, please post your stack trace and describe what is not working.

@brucejcw I fixed the link

I think it is not included in node_redis documentation, even the set function.
Maybe it'll confuse some people.

@bruceCzK There is no explicit commands documentation. And this would not be a good idea in general as the commands might change in Redis and new parameters might be added over time.

But there is more than one reference to the main documentation that you should always look at to see how the commands work. If you see any possibility to improve the current documentation, please feel free to open a pull request for it. It might be a good idea to add the link on all "commands" occurrences in the README.md.

hey guys, is there a way to set default expire at the client level?

Ex: something like

  const redisClient = redis.createClient({
    host: process.env.REDIS_ENDPOINT,
    port: process.env.REDIS_PORT,
    expire: 60 
})

Just echoing that this is a super confusing syntax, especially to newcomers. There is nothing in node_redis documentation about key expirations/TTLs. I would imagine most people use Redis as part of a caching layer and expiration time for keys would be a really important part of that workflow. IMO, this should either be baked into the basic API (perhaps the set function can take in an optional parameter) or the documentation should at least talk about the command API as it relates to key expiration.

looks like the answer is no that we can't set global expire at the client level. It's kind of suck to have to set expire on every single key.

@ryanvanderpol the set function already takes a optional parameter as described. Just look at the documentation and at my comment above.

@kienpham2000 There is no global expire at the client level and this would be difficult to implement. Each command would have to be checked and manipulated. Instead, a new feature to add hooks could solve that.
This is not a caching library and likely you're looking for that instead.

@BridgeAR: Understood, but you're kind of missing the point. Perhaps this is just me being lazy, but I refuse to learn the entire native Redis API just so I can stick things in and pull things out. Maybe I shouldn't be using the node_redis library then. Maybe I should be using something else that sits on top of it and abstracts this away from me. However, like I said before, I think most people use Redis as a cache and there is nothing in the node_redis documentation that even mentions the word "expire" or "expiration" (or even the "EX" command or TTLs) so without digging into the official Redis documentation it's hard to understand how to actually set a TTL for a key, an action that I expect the majority of people will need to do.

@ryanvanderpol It's a Redis client library, not a cache library. If you use a Redis library, you are kind of expected to read the Redis documentation, especially because node_redis does not document how the commands work, for this very reason. After all, node_redis just forwards the parameters to Redis most of the time.

If you want a cache library, you can use one of the many npm packages out there, such as cacheman-redis or node-redis-cache, in their documentation you will find explicit mentioning of "expire" :smile:

I understand your point, but I think it shouldn't be the job of node_redis to duplicate the documentation of Redis or abstract things away more than necessary...

@CherryDT your point is fair, which is also why I prefaced my previous comment with "maybe i should be using something else that sits on top of node_redis", but given how many +1's my comment has received so far, I have no doubt that I am not alone in this frustration.

If all I wanted to do was communicate directly with Redis in a raw format, then this wrapper doesn't really provide much value for me. I think it's completely fair to assume that the vast majority of people using Redis are doing so for caching purposes and will care about expirations.

This whole conversation could have just been negated with a "good point, we should add a bit to the documentation about how to set key expirations, along with some other commonly used commands". I suppose I could also submit a PR for that as well, but I'm not familiar with Redis outside of using it as a cache.

That said I'll look at the other libraries you mentioned and I might move to one of those instead if they suit my use case better.

My point is that there is a lot more functionality than TTLs. There are different data types (lists, sets, sorted sets), a publisher & subscriber system and more, and basically duplicating the documention of Redis (and keeping it updated), or adding more sugar on the parameters (and keeping _them_ updated) are things which I believe are outside the scope of this client. I wouldn't expect from a MySQL client the features of an ORM (or a MySQL reference) either, would you?

I believe in modular design, and hence I also believe that the individual modules shouldn't be larger than they need to be. And in this case, this client does a great job in abstracting the networking part and providing the commands as methods for a first layer of convenience, but I think that things on top of that should be the job of more specialized libraries for the specific goals (such as those I linked before for cache, or others for pubsub, etc.). Those often use node_redis interally, by the way, So even if it may not be of much use for you directly, it can be indirectly, because the more abstracted libraries you may use maybe use node_redis as dependency.

So, I agree that for your use case you would be better off with a more "high-level" library on top of something like node_redis.

Yeah, I completely disagree with you here. I would expect the documentation for a MySQL client to show me how to do some of the common stuff everyone does in MySQL, like how do I do a select with an aggregate function or how do I do a subquery. I don't expect it to explain how to build an ORM or be a reproduction of the entire MySQL documentation, but show me how I do common stuff using the library.

Anyway, clearly you're not going to see my point of view and this is a waste of time. So far, 17 people agree with me and only you and one other person disagree. So, maybe you should step back and think about how you can see things from other people's perspective once in a while.

Why do you make this personal? I totally understand your point, I just think that node_redis is not the right tool for the job then. (As you agreed yourself before I even started making my point.) Think about it, keeping things small and self-contained simplifies a lot of things. node_redis worries about networking, things like node-cache-redis (or your own implementation) worry about using the Redis API correctly. This way, there are not so many dependencies. Libraries "on top" will always exist in one way or another, and this way node_redis doesn't need to be updated (or even support different API versions) every time Redis adds or changes some feature (only when it adds a whole _command_).

I offered you alternative solutions, and I hope these will fulfill your needs, and if not, take a moment to search for "redis" on npm and you will finds tons of other libraries as well.

Let's just agree that we disagree on this. (And it doesn't matter if 17 or 1700 people agree with you or me. Every opinion should be valued, I think.)

If we look at the original question and the answer, I didn't know I have to use .set() with 'EX' and time options like that in this library.

Looking at the current README.md, it explains how to use client.hgetall (https://github.com/NodeRedis/node_redis#clienthgetallhash-callback) , perhaps we can add in few more common case for SET and GET in similar fashion? I'm also assuming people use at lot of GET and SET with redis.

I was not aware that so many people had issues with that as the likes do not show up in my inbox.

I would be up for a PR that documents the set command as an example while also mentioning "expire".

I would also like to have a PR that documents that this is not a cache library and that it is not intended to be one. I'm open for any input on how to make the documentation better for new people.

@kienpham2000 Well, it's also a separate command - setex :)

Just to chime in here about explaining _redis_ in the _node_redis_ module readme. I'm not entirely sold on the idea. As the illustrated by this example - using set and expire in a multi/exec, using setex or using set with 'ex' - there are a tons of ways to do many things. None of which has anything to do with node. We explain hgetall because it departs from how other commands return values.

Not to say that people don't have questions, but it seems to me that writing a blog or medium post or something is a better way to inform people rather than concentrating it here. If we get the question, it can just be linked in any issues that come up. Turning the _node_redis_ module readme into the source all for knowledge is maybe out of scope.

@stockholmux I'm just curious how do we use setex in this lib? Is it just client.setex()?

If this lib is 1-1 mapping with redis commands then I think we don't need doc. But if this lib has special api or diff way to pass in options, I think having some type of API doc would be very helpful for devs.

@kienpham2000 it is a 1-to-1 mapping. It was always meant to be one. A simple client to use the API. This is low level, not high level.

And @stockholmux is right that hgetall is only documented because you may use it in more ways than any other command. But it is still a 1-to-1 mapping.

Anyhow: I'm in favor of adding a section about this so this does not come up again.

@BridgeAR cool thanks for willing to accept this doc PR, here is my 1st draft: https://github.com/NodeRedis/node_redis/pull/1229/files

Updated: https://github.com/NodeRedis/node_redis/pull/1380

Now I found this and it looks like another method: https://dzone.com/articles/tutorial-working-nodejs-and

I couldn't get that method working either (no error, just no effect so I'm abandoning this project and switching to https://www.npmjs.com/package/node-cache which can use Redis anyway.

Under windows is not possible set the expiration within "set" method with 'EX', 20 because only accepts 2 parameters instead o 3.

Maybe you have an old Redis version? The docs say it was added in Redis 2.6.12: https://redis.io/commands/set

You can use SETEX instead, which exists since 2.0.0...

Maybe you have an old Redis version? The docs say it was added in Redis 2.6.12: https://redis.io/commands/set

I am using redis in a node-express project, with JS is not possible to add three parameters (or I am not being able.. :-( )

redis.set("cache:" + req.originalUrl, JSON.stringify(result), 'EX', 25); --> this is my code with error in the expiration area.

Which Redis version?

Redis 2.4.5 for windows redis-windows and lastest version of node module.

So then it's clear, please read me message above again and check the Redis documentation! The "EX" parameter in SET was only added in 2.6.12, so your Redis version 2.4.5 doesn't have it, but you can instead use SETEX which exists since 2.0.0.

redis.setex(key, seconds, value)
redis.setex(key, value, seconds)

redis.setex(key, value, expiration) --> that is not working

...but I have found one correct way in this link : redis windows

If you want to change your Redis version, yes, your way is right of course.
If not, mine works too, I just got the parameters wrong (but if you had checked the SETEX docs, you would have noticed): it's key, seconds, value and not key, values, seconds.

Anyhow, great to hear that it works for you now.

The below doesn't work.

client.set('key', 'value', 'EX', 10, (error, replay)=>{
...
}

Any updated on this ?
I am using client.expire(id,10) for now.

PS : I am using redis version : Redis server v=5.0.0 and node verison : v8.10.0

@kdthanvi That should work. Double check what's actually happening using MONITOR from redis-cli when running it.

@kdthanvi is right. It does not work with redis 5:

client.set(key, value, 'EX', 60 * 60 * 24, callback);

You need:

`
client.set(key, value, callback);

client.expire(key, TTL, callback);
`

to make it actually work.

@martinlevesque I believe you are mistaken. EX was added in 2.6.12 and node_redis correctly passes 'EX' no matter the version. Check with MONITOR and you'll see.

SET + EXPIRE can be dangerously different than SET .. EX due to atomic differences.

Because this thread is number 1 when I search "Redis node set expire", I would like to make it a point to conclude the follow set expire command works with nodeJS redis as of today.

setex(key, 60, value)

Where 60 is the expire time in seconds.

Because this thread is number 1 when I search "Redis node set expire", I would like to make it a point to conclude the follow set expire command works with nodeJS redis as of today.

setex(key, 60, value)

Where 60 is the expire time in seconds.

Found this after 2hrs of debugging and error solving. Thank you so much ;)