1085 Avons-nous un support pour le support du drapeau NX/XX pour les commandes comme ZADD

Cela fait quelques mois, y a-t-il un calendrier mis à jour sur ce front ?

+1

Une prise en charge du cluster/sharding sera-t-elle bientôt disponible ? AWS prend en charge les clusters Redis sur ElastiCache et j'aimerais l'utiliser, mais cette bibliothèque doit rattraper cet ensemble de fonctionnalités pour que cela soit vraiment viable :(

Ce problème devrait être épinglé à mon humble avis

De plus, https://github.com/gosquared/redis-clustr pourrait être une solution suffisante pour la prise en charge du cluster ?

Un emballage équivalent pour la sentinelle serait formidable. Peut-être https://www.npmjs.com/package/redis-sentinel mais semble un peu mort (4 ans depuis la dernière publication).

Peut-être devrions-nous discuter de l'avenir de ce référentiel ici ; la dernière publication sur NPM de ce package remonte à plus de 2 ans, il y a des correctifs sur master qui n'ont pas été publiés sur NPM depuis près de 2 ans, par exemple https://github.com/NodeRedis/node_redis/issues/1331 ;

Notez que ce n'est pas moi qui me plains de @BridgeAR , il fait en fait un excellent travail dans @nodejs , il est donc compréhensible que son temps pour ce référentiel soit limité.

Je suis prêt à prendre en charge une partie du fardeau de la maintenance, mais j'aimerais avoir des réflexions sur la marche à suivre que nous pourrions prendre pour cela étant donné que l'accès de publication NPM n'est pas disponible pour le référentiel existant (je l'ai demandé plusieurs fois au fil des ans) .

À l'heure actuelle, il semble que la seule option soit de bifurquer et de recommencer, à moins que nous n'obtenions l'accès.

@Salakar Je suis également prêt à aider à faire avancer ce paquet. Je ne sais pas trop pourquoi nous devons abandonner le nom du package NPM ("redis" est puissant). @BridgeAR ne contrôle-t-il pas le package NPM et doit-il le transférer à quelqu'un ? Il y a eu peu d'action depuis de nombreux mois, et je ne comprends pas très bien la logique de rester assis là-dessus, pour être honnête.

Je ne pense pas que nous devrions déprécier ce paquet - c'est une bonne base de code qui peut être mise à jour et un grand nombre d'autres paquets en dépendent.

L'autre chose que j'aimerais aborder concerne les changements à venir de RESP3 / Redis 6 qui nécessiteront des modifications importantes. J'ai examiné la fonctionnalité ACL dans Redis 6 qui devrait être facile à prendre en charge, mais nous aurons besoin d'une refactorisation sérieuse pour node_redis. Mon travail (chez Redis Labs) soutiendrait mon travail sur ce module, mais si nous ne pouvons pas faire une version NPM, cela n'a pas de sens d'investir du temps.

@BridgeAR ne contrôle-t-il pas le package NPM et doit-il le transférer à quelqu'un ? Il y a eu peu d'action depuis de nombreux mois, et je ne comprends pas très bien la logique de rester assis là-dessus, pour être honnête.

Correct, mais je demande l'accès à la publication NPM depuis février 2018, à nouveau en février 2019, et la demande la plus récente en septembre 2019. J'ai eu des réponses, mais pas sur le sujet de la demande d'accès à la publication NPM 🤷‍♂. https://github.com/NodeRedis/node_redis/issues/1402#issuecomment -490273744 donne peut-être une indication des intentions ?

Si le transfert n'a pas lieu, je pense qu'il faut le préciser pour que nous puissions passer à autre chose.

ioredis, par exemple, est vraiment sympa, et il a été question de consolider les bibliothèques à l'époque (j'ai travaillé sur certains des outils sous-jacents pour cela, tels que le nouvel analyseur, denque lib, cluster key slot calc, etc.): https:// github.com/NodeRedis/node_redis#consolidation -its -time-for-celebration - qui, je pense toujours, devrait être l'objectif à long terme ?

Hors sujet, mais j'ai commencé à expérimenter la création d'un nouveau client il y a quelque temps; https://twitter.com/mikediarmid/status/1074240036936318976 - mais je me suis arrêté là-dessus dans l'espoir de relancer celui-ci ou d'aider à consolider;

C'est peut-être aussi un itinéraire 🤷‍♂

@Salakar avez-vous parlé à l'un des autres propriétaires de NPM (Matt, Ben ou Bryce) ? Si Ruben est MIA, alors si nous voulons que le projet avance, je ne pense pas qu'une seule personne devrait être un obstacle. Ce genre de problème est la raison pour laquelle il a été configuré de cette façon, je suppose. Je trouve le commentaire sur 1402 troublant pour un projet open source, en particulier celui qui n'est pas lié (organisationnellement) à une seule personne.

Je suis d'accord, ioredis est bon mais je ne pense pas que ce soit une solution unique. En ce qui concerne la consolidation, je pensais que l'analyseur unifié était le principal objectif déjà atteint. Je n'ai jamais pensé qu'il y aurait entièrement un seul module, juste compte tenu des différences de syntaxe.

@stockholmux : Mon travail (chez Redis Labs) soutiendrait mon travail sur ce module, mais si nous ne pouvons pas faire une version NPM, cela n'a pas de sens d'investir du temps.

Idem aussi, nous sommes prêts à consacrer des ressources à cela aussi @invertase , mais si nous ne pouvons pas le publier, cela n'a pas de sens pour nous non plus.

@stockholmux : @Salakar avez-vous parlé à l'un des autres propriétaires de NPM (Matt, Ben ou Bryce) ?

C'est un bon point, je n'en ai pas, je vais les contacter sous peu.

@stockholmux : Je suis d'accord, ioredis est bon mais je ne pense pas que ce soit une solution unique. En ce qui concerne la consolidation, je pensais que l'analyseur unifié était le principal objectif déjà atteint. Je n'ai jamais pensé qu'il y aurait entièrement un seul module, juste compte tenu des différences de syntaxe.

Par intérêt, quelles sont vos exigences auxquelles la redis répond mais pas ioredis ? Mes exigences impliquaient le clustering et la sentinelle que redis ne prend actuellement pas en charge, sauf si certains packages tiers, dont certains ont également été abandonnés.

Peut-être que les protocoles de connexion sous-jacents entre les deux bibliothèques pourraient également être partagés, alors c'est simplement comment vous vous connectez avec chacun qui est différent?

@Salakar J'aime l'approche modulaire de la sentinelle et du regroupement par rapport à l'approche monolithique d'ioredis (encore une fois, nous devons faire face à l'abandonware). Certaines personnes en ont besoin, d'autres non. L'écosystème global de Redis s'agrandit et la modularité est le moyen de prendre en charge plus sans complexité, à mon humble avis. Ioredis est une base de code beaucoup plus grande (18 897 contre 7 038 lignes de code), ce qui peut être plus de fonctionnalités, mais je préférerais ne pas avoir autant de choses supplémentaires que je n'utilise pas.

L'endroit où je pense que node_redis a un gros avantage est le support du module Redis, ce qui est facile avec node_redis et plutôt pénible avec ioredis.

J'ai contacté @mranney via les DM de Twitter et lui ai demandé s'il pouvait m'accorder, ainsi qu'au propriétaire de @stockholmux , l'accès à l'organisation GitHub et aux packages NPM, nous verrons donc ce qui en découle.

Je pense que @stockholmux et moi-même sommes d'accord sur le fait que tout maintenir et publier à partir de là où ils se trouvent actuellement est la meilleure voie à suivre - si nous en sommes capables. Sinon, je suppose que nous pouvons envisager des alternatives, bien que je préfère ne pas le faire.

Une petite suggestion. Vous devriez peut-être envisager de migrer le code source vers TypeScript.

Salut tout le monde, j'ai pris la relève en tant que mainteneur principal et j'ai maintenant tous les accès requis 🎉 un grand merci à @BridgeAR pour tout le travail qu'il a fait (et fait) sur cette bibliothèque et pour m'avoir laissé prendre le relais.

J'ai passé les derniers jours à préparer le maître pour une version, et il y a quelques minutes, je viens de publier la v3.0.0 sur NPM ; https://github.com/NodeRedis/node-redis/releases/tag/v3.0.0 - qui inclut ce changement.

Attendez-vous à des publications régulières - ma première priorité pour le moment est de rendre ce projet plus convivial pour les contributeurs afin de m'assurer que le projet vit et continue de croître et qu'il n'est pas bloqué par le temps d'une personne singulière. Pour ce faire, j'aimerais développer un ensemble plus large de contributeurs superficiels. Avec cela, j'espère atténuer le problème précédent du projet nécessitant des mises à jour, mais personne n'a le pouvoir de le faire. Je travaille sur ce qui suit;

• [x] Contribuer à la documentation et au code de conduite
• [x] Mettre en place un Open Collective et une politique de dépenses des contributeurs
  
  
  
  • Vous remarquerez le nouveau bouton brillant Sponsor en haut de GitHub, j'ai également pris les devants et l'ai parrainé moi-même et par l'intermédiaire de mon entreprise pour aider à le lancer pour tous les futurs contributeurs
  
  
• WIP : Automatisation des versions et gestion des versions sémantiques (publication sur NPM, génération de journaux des modifications, etc.)
• [x] Améliorer CI, par exemple Windows CI est super lent et floconneux en ce moment

Après cela, je porterai mon attention sur la modernisation (par exemple, les promesses, le texte dactylographié) et la suppression de la dette technique dans la base de code Node Redis. @BridgeAR a déjà fait un tas de choses pour cela, si vous êtes curieux, consultez la branche WIP v4 et son journal des modifications.

@Salakar Félicitations ! Je voulais reprendre le travail des promesses (j'adorerais abandonner async-redis ) mais je suppose que c'est presque terminé maintenant. Vous avez une idée d'un délai ? Acceptez-vous des contributions sur ce front (par exemple : avons-nous une sorte de liste de contrôle) ?

Hey @GCSBOSS , consultez la branche 'v4' - c'est le refactoring en cours, qui a un support promis, pas d'eta / délai mais encore désolé