Node-redis: comment définir l'heure d'expiration

Veuillez vérifier les commandes de découmentation . Chaque partie a son propre paramètre, vous écririez donc quelque chose comme:

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

Merci

@BridgeAR le lien de documentation ne fonctionne pas

ça ne marche pas .. redis version 3.0

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

@sxyjijiji cela fonctionne parfaitement bien pour moi. Si vous rencontrez une erreur, veuillez publier votre trace de pile et décrire ce qui ne fonctionne pas.

@brucejcw j'ai corrigé le lien

Je pense que ce n'est pas inclus dans la documentation node_redis, même la fonction set.
Peut-être que cela déroutera certaines personnes.

@bruceCzK Il n'y a pas de documentation explicite sur les commandes. Et ce ne serait pas une bonne idée en général car les commandes pourraient changer dans Redis et de nouveaux paramètres pourraient être ajoutés au fil du temps.

Mais il y a plus d'une référence à la documentation principale que vous devriez toujours consulter pour voir comment les commandes fonctionnent. Si vous voyez une possibilité d'améliorer la documentation actuelle, n'hésitez pas à ouvrir une pull request. Il peut être judicieux d'ajouter le lien sur toutes les occurrences de "commandes" dans le fichier README.md.

hé les gars, existe-t-il un moyen de définir l'expiration par défaut au niveau du client?

Ex: quelque chose comme

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

Je rappelle simplement qu'il s'agit d'une syntaxe très déroutante, en particulier pour les nouveaux arrivants. Il n'y a rien dans la documentation de node_redis sur les expirations / TTL de clés. J'imagine que la plupart des gens utilisent Redis dans le cadre d'une couche de mise en cache et que le délai d'expiration des clés serait une partie vraiment importante de ce flux de travail. OMI, cela devrait soit être intégré dans l'API de base (peut-être que la fonction set peut prendre un paramètre facultatif) ou la documentation devrait au moins parler de l'API de commande en ce qui concerne l'expiration de la clé.

ressemble à la réponse est non que nous ne pouvons pas définir l'expiration globale au niveau du client. C'est un peu nul de devoir expirer sur chaque touche.

@ryanvanderpol la fonction set prend déjà un paramètre optionnel comme décrit. Regardez simplement la documentation et mon commentaire ci-dessus.

@ kienpham2000 Il n'y a pas d'expiration globale au niveau du client et cela serait difficile à implémenter. Chaque commande devrait être vérifiée et manipulée. Au lieu de cela, une nouvelle fonctionnalité pour ajouter des hooks pourrait résoudre ce problème.
Ce n'est pas une bibliothèque de mise en cache et vous la recherchez probablement à la place.

@BridgeAR : Compris, mais vous manquez un peu le point. Peut-être que c'est juste moi qui suis paresseux, mais je refuse d'apprendre toute l'API native de Redis juste pour que je puisse coller et retirer les choses. Peut-être que je ne devrais pas utiliser la bibliothèque node_redis alors. Peut-être que je devrais utiliser quelque chose d'autre qui se trouve au-dessus de cela et qui me fait abstraction de cela. Cependant, comme je l'ai déjà dit, je pense que la plupart des gens utilisent Redis comme cache et il n'y a rien dans la documentation node_redis qui mentionne même le mot "expire" ou "expiration" (ou même la commande "EX" ou TTL) donc sans fouiller dans la documentation officielle de Redis, il est difficile de comprendre comment définir réellement un TTL pour une clé, une action que je pense que la majorité des gens devra faire.

@ryanvanderpol C'est une bibliothèque cliente Redis, pas une bibliothèque cache. Si vous utilisez une bibliothèque Redis, vous êtes en quelque sorte censé lire la documentation Redis, en particulier parce que node_redis ne documente pas le fonctionnement des commandes, pour cette raison même. Après tout, node_redis transmet simplement les paramètres à Redis la plupart du temps.

Si vous voulez une bibliothèque de cache, vous pouvez utiliser l'un des nombreux packages npm, tels que cacheman-redis ou node-redis-cache , dans leur documentation, vous trouverez une mention explicite de "expire": smile:

Je comprends votre point, mais je pense que ce ne devrait pas être le travail de node_redis de dupliquer la documentation de Redis ou d'abstraire des choses plus que nécessaire ...

@CherryDT votre point est juste, c'est aussi pourquoi j'ai préfacé mon commentaire précédent par "peut-être que je devrais utiliser quelque chose d'autre qui se trouve au-dessus de node_redis", mais étant donné le nombre de +1 que mon commentaire a reçu jusqu'à présent, je n'ai aucun doute que je ne suis pas seul dans cette frustration.

Si tout ce que je voulais faire était de communiquer directement avec Redis dans un format brut, alors ce wrapper ne me fournit pas vraiment beaucoup de valeur. Je pense qu'il est tout à fait juste de supposer que la grande majorité des personnes utilisant Redis le font à des fins de mise en cache et se soucieront des expirations.

Toute cette conversation aurait pu juste être annulée avec un "bon point, nous devrions ajouter un peu à la documentation sur la façon de définir les expirations de clés, ainsi que quelques autres commandes couramment utilisées". Je suppose que je pourrais également soumettre un PR pour cela, mais je ne suis pas familier avec Redis en dehors de son utilisation comme cache.

Cela dit, je vais regarder les autres bibliothèques que vous avez mentionnées et je pourrais passer à l'une d'entre elles à la place si elles correspondent mieux à mon cas d'utilisation.

Mon point est qu'il y a beaucoup plus de fonctionnalités que les TTL. Il existe différents types de données (listes, ensembles, ensembles triés), un système d'éditeur et d'abonné et plus encore, et la duplication de la documentation de Redis (et la mise à jour), ou l'ajout de plus de sucre sur les paramètres (et en les gardant à jour) des choses qui, je crois, sont hors de la portée de ce client. Je n'attendrais pas non plus d'un client MySQL les fonctionnalités d'un ORM (ou d'une référence MySQL), n'est-ce pas?

Je crois en la conception modulaire, et par conséquent, je pense également que les modules individuels ne devraient pas être plus grands qu'ils ne devraient l'être. Et dans ce cas, ce client fait un excellent travail en résumant la partie réseau et en fournissant les commandes en tant que méthodes pour une première couche de commodité, mais je pense que les choses en plus devraient être le travail de bibliothèques plus spécialisées pour les objectifs spécifiques. (comme ceux que j'ai liés auparavant pour le cache, ou d'autres pour pubsub, etc.). Celles-ci utilisent souvent node_redis en interne, d'ailleurs, donc même si cela peut ne pas être d'une grande utilité pour vous directement, cela peut être indirectement, car les bibliothèques plus abstraites que vous pouvez utiliser peuvent utiliser node_redis comme dépendance.

Donc, je suis d'accord que pour votre cas d'utilisation, vous seriez mieux avec une bibliothèque plus "de haut niveau" en plus de quelque chose comme node_redis.

Ouais, je suis complètement en désaccord avec toi ici. Je m'attendrais à ce que la documentation d'un client MySQL me montre comment faire certaines des choses courantes que tout le monde fait dans MySQL, comme comment faire une sélection avec une fonction d'agrégation ou comment faire une sous-requête. Je ne m'attends pas à ce qu'il explique comment construire un ORM ou qu'il soit une reproduction de toute la documentation MySQL, mais montre-moi comment je fais des choses courantes en utilisant la bibliothèque.

Quoi qu'il en soit, il est clair que vous n'allez pas voir mon point de vue et c'est une perte de temps. Jusqu'à présent, 17 personnes sont d'accord avec moi et seuls vous et une autre personne n'êtes pas d'accord. Alors, peut-être devriez-vous prendre du recul et réfléchir à la façon dont vous pouvez voir les choses du point de vue des autres de temps en temps.

Pourquoi rendez-vous cela personnel? Je comprends tout à fait votre point, je pense juste que node_redis n'est pas le bon outil pour le travail alors. (Comme vous l'avez convenu vous-même avant même de commencer à faire valoir mon point de vue.) Pensez-y, garder les choses petites et autonomes simplifie beaucoup de choses. node_redis s'inquiète de la mise en réseau, des choses comme node-cache-redis (ou votre propre implémentation) s'inquiètent de l'utilisation correcte de l'API Redis. De cette façon, il n'y a pas autant de dépendances. Les bibliothèques "en haut" existeront toujours d'une manière ou d'une autre, et de cette manière node_redis n'a pas besoin d'être mis à jour (ni même de prendre en charge différentes versions d'API) chaque fois que Redis ajoute ou modifie une fonctionnalité (uniquement lorsqu'il ajoute une _commande_ entière) .

Je vous ai proposé des solutions alternatives, et j'espère que celles-ci répondront à vos besoins. Sinon, prenez un moment pour rechercher "redis" sur npm et vous trouverez également des tonnes d'autres bibliothèques.

Convenons simplement que nous ne sommes pas d'accord sur ce point. (Et peu importe si 17 ou 1700 personnes sont d'accord avec vous ou moi. Chaque opinion doit être appréciée, je pense.)

Si nous regardons la question originale et la réponse, je ne savais pas que je devais utiliser .set() avec 'EX' et des options de temps comme ça dans cette bibliothèque.

En regardant le README.md actuel, il explique comment utiliser client.hgetall (https://github.com/NodeRedis/node_redis#clienthgetallhash-callback), peut-être pouvons-nous ajouter quelques cas plus courants pour SET et GET de la même manière? Je suppose également que les gens utilisent beaucoup de GET et SET avec redis.

Je ne savais pas que tant de gens avaient des problèmes avec cela car les likes n'apparaissent pas dans ma boîte de réception.

Je serais partant pour un PR qui documente la commande set comme exemple tout en mentionnant également «expire».

J'aimerais aussi avoir un PR qui atteste que ce n'est pas une bibliothèque de cache et qu'il n'est pas destiné à en être une. Je suis ouvert à toute contribution sur la façon d'améliorer la documentation pour les nouvelles personnes.

@ kienpham2000 Eh bien, c'est aussi une commande séparée - setex :)

Juste pour expliquer ici comment expliquer _redis_ dans le fichier readme du module _node_redis_. Je ne suis pas entièrement convaincu par l'idée. Comme illustré par cet exemple - en utilisant set et expire dans un multi / exec , en utilisant setex ou en utilisant set avec «ex» - il existe une multitude de façons de faire beaucoup de choses. Tout cela n'a rien à voir avec node. Nous expliquons hgetall car il diffère de la manière dont les autres commandes renvoient des valeurs.

Pour ne pas dire que les gens n'ont pas de questions, mais il me semble qu'écrire un blog, un article médiatique ou quelque chose comme ça est un meilleur moyen d'informer les gens plutôt que de le concentrer ici. Si nous recevons la question, elle peut simplement être liée à tous les problèmes qui surviennent. Transformer le fichier readme du module _node_redis_ en source tout pour la connaissance est peut-être hors de portée.

@stockholmux Je suis juste curieux de savoir comment utiliser setex dans cette bibliothèque? Est-ce juste client.setex() ?

Si cette bibliothèque est un mappage 1-1 avec les commandes redis, je pense que nous n'avons pas besoin de doc. Mais si cette bibliothèque a une api spéciale ou une méthode diff pour passer des options, je pense qu'avoir un type de document API serait très utile pour les développeurs.

@ kienpham2000 c'est un mappage 1-to-1. C'était toujours censé en être un. Un client simple pour utiliser l'API. C'est un niveau bas, pas un niveau élevé.

Et @stockholmux a raison de dire que hgetall n'est documenté que parce que vous pouvez l'utiliser de plus de manières que toute autre commande. Mais il s'agit toujours d'un mappage 1 à 1.

Quoi qu'il en soit: je suis en faveur de l'ajout d'une section à ce sujet afin que cela ne revienne plus.

@BridgeAR merci d'avoir accepté ce doc PR, voici mon premier brouillon: https://github.com/NodeRedis/node_redis/pull/1229/files

Mis à jour: https://github.com/NodeRedis/node_redis/pull/1380

Maintenant, j'ai trouvé cela et cela ressemble à une autre méthode: https://dzone.com/articles/tutorial-working-nodejs-and

Je n'ai pas pu faire fonctionner cette méthode non plus (pas d'erreur, juste aucun effet, donc j'abandonne ce projet et je passe à https://www.npmjs.com/package/node-cache qui peut de toute façon utiliser Redis.

Sous Windows, il n'est pas possible de définir l'expiration dans la méthode "set" avec 'EX', 20 car n'accepte que 2 paramètres au lieu de o 3.

Peut-être avez-vous une ancienne version de Redis? La documentation indique qu'il a été ajouté dans Redis 2.6.12: https://redis.io/commands/set

Vous pouvez utiliser SETEX à la place, qui existe depuis 2.0.0 ...

Peut-être avez-vous une ancienne version de Redis? La documentation indique qu'il a été ajouté dans Redis 2.6.12: https://redis.io/commands/set

J'utilise redis dans un projet node-express, avec JS n'est pas possible d'ajouter trois paramètres (ou je ne peux pas .. :-()

redis.set("cache:" + req.originalUrl, JSON.stringify(result), 'EX', 25); -> ceci est mon code avec une erreur dans la zone d'expiration.

Quelle version de Redis?

Redis 2.4.5 pour Windows Redis-Windows et la dernière version du module de nœud.

Alors c'est clair, lisez-moi à nouveau le message ci-dessus et consultez la documentation Redis! Le paramètre "EX" dans SET n'a été ajouté que dans la version 2.6.12, donc votre version 2.4.5 de Redis ne l'a pas, mais vous pouvez à la place utiliser SETEX qui existe depuis 2.0.0.

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

redis.setex(key, value, expiration) -> qui ne fonctionne pas

... mais j'ai trouvé un moyen correct dans ce lien: redis windows

Si vous souhaitez changer votre version de Redis, oui, votre chemin est bien sûr.
Sinon, le mien fonctionne aussi, je me suis juste trompé de paramètres (mais si vous aviez vérifié la documentation SETEX, vous l'auriez remarqué): c'est la clé, les secondes, la valeur et non la clé, les valeurs, les secondes.

Quoi qu'il en soit, super d'entendre que cela fonctionne pour vous maintenant.

Le ci-dessous ne fonctionne pas.

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

Des mises à jour à ce sujet?
J'utilise client.expire(id,10) pour le moment.

PS: J'utilise la version redis: Redis server v=5.0.0 et la version du nœud: v8.10.0

@kdthanvi Cela devrait fonctionner. Vérifiez ce qui se passe réellement en utilisant MONITOR de redis-cli lors de son exécution.

@kdthanvi a raison. Cela ne fonctionne pas avec redis 5:

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

Vous avez besoin:

»
client.set (clé, valeur, rappel);

client.expire (clé, TTL, rappel);
»

pour que cela fonctionne réellement.

@martinlevesque Je crois que vous vous trompez. EX été ajouté dans 2.6.12 et node_redis passe correctement 'EX' quelle que soit la version. Vérifiez avec MONITOR et vous verrez.

SET + EXPIRE peut être dangereusement différent de SET .. EX raison de différences atomiques.

Parce que ce fil est le numéro 1 lorsque je recherche "Redis node set expire", je voudrais me faire un point pour conclure que la commande follow set expire fonctionne avec nodeJS redis dès aujourd'hui.

setex(key, 60, value)

Où 60 est le temps d'expiration en secondes.

Parce que ce fil est le numéro 1 lorsque je recherche "Redis node set expire", je voudrais me faire un point pour conclure que la commande follow set expire fonctionne avec nodeJS redis dès aujourd'hui.

setex(key, 60, value)

Où 60 est le temps d'expiration en secondes.

J'ai trouvé cela après 2 heures de débogage et de résolution d'erreurs. Merci beaucoup ;)