1085 Temos suporte para suporte de sinalizador NX/XX para comandos como ZADD

Já faz alguns meses, há algum cronograma atualizado nessa frente?

+1

Alguma chance de suporte a cluster/sharding chegar em breve? A AWS tem suporte a cluster redis no ElastiCache e eu gostaria de usá-lo, mas essa lib precisa acompanhar esse conjunto de recursos para que isso seja realmente viável :(

Este problema deve ser fixado IMHO

Também https://github.com/gosquared/redis-clustr pode ser uma solução boa o suficiente para suporte de cluster?

Um wrapper equivalente para sentinela seria ótimo. Talvez https://www.npmjs.com/package/redis-sentinel , mas parece meio morto (4 anos desde a última publicação).

Talvez devêssemos discutir o futuro deste repositório aqui; a última publicação no NPM deste pacote foi há mais de 2 anos, há correções no master que não foram publicadas no NPM por quase 2 anos, ex: https://github.com/NodeRedis/node_redis/issues/1331;

Observe que não sou eu reclamando de @BridgeAR , ele está realmente fazendo um ótimo trabalho em @nodejs , portanto, compreensivelmente, seu tempo para este repositório é limitado.

Estou disposto a assumir parte da carga de manutenção, mas gostaria de algumas ideias sobre o curso de ação que poderíamos tomar para isso, já que o acesso de publicação do NPM não está disponível para o repositório existente (solicitei várias vezes ao longo dos anos) .

No momento, parece que a única opção é bifurcar e começar de novo, a menos que tenhamos acesso.

@Salakar Também estou disposto a ajudar a levar esse pacote adiante. Não tenho certeza por que precisamos abandonar o nome do pacote NPM ('redis' é poderoso). O @BridgeAR não controla o pacote NPM e precisa transferi-lo para alguém? Houve pouca ação em muitos meses, e eu não entendo muito bem a lógica de apenas sentar nela, para ser honesto.

Eu não acho que deveríamos depreciar este pacote - é uma boa base de código que pode ser atualizada e um grande número de outros pacotes dependem dele.

A outra coisa que eu gostaria de destacar são as próximas mudanças no RESP3 / Redis 6 que exigirão alterações significativas. Analisei o recurso ACL no Redis 6, que deve ser fácil de suportar, mas precisaremos de uma refatoração séria para node_redis. Meu trabalho (no Redis Labs) apoiaria meu trabalho neste módulo, mas se não pudermos fazer um lançamento do NPM, não faz sentido investir tempo.

O @BridgeAR não controla o pacote NPM e precisa transferi-lo para alguém? Houve pouca ação em muitos meses, e eu não entendo muito bem a lógica de apenas sentar nela, para ser honesto.

Correto, mas estou solicitando acesso de publicação do NPM desde fevereiro de 2018, novamente em fevereiro de 2019 e a solicitação mais recente em setembro de 2019. Recebi respostas, mas não sobre solicitação de acesso de publicação do NPM 🤷‍♂. https://github.com/NodeRedis/node_redis/issues/1402#issuecomment -490273744 talvez dê alguma indicação de intenções?

Se a transferência não for acontecer, acho que precisa ficar claro para que possamos seguir em frente.

ioredis, por exemplo, é muito bom, e houve conversas sobre consolidar as bibliotecas no passado (eu trabalhei em algumas das ferramentas subjacentes para isso, como o novo analisador, denque lib, calc de slot de chave de cluster etc): https:// github.com/NodeRedis/node_redis#consolidation -its -time-for-celebration - que eu ainda acho que deveria ser o objetivo de longo prazo?

Fora do tópico, mas eu comecei a experimentar a construção de um novo cliente um tempo atrás; https://twitter.com/mikediarmid/status/1074240036936318976 - mas parei na esperança de recomeçar ou ajudar a consolidar;

Talvez isso também seja uma rota 🤷‍♂

@Salakar você conversou com algum dos outros proprietários do NPM (Matt, Ben ou Bryce)? Se Ruben está desaparecido, então se queremos que o projeto avance, não acho que uma única pessoa deva ser um obstáculo. Esse tipo de problema é o motivo pelo qual foi configurado dessa maneira, suponho. Acho o comentário sobre 1402 preocupante para um projeto de código aberto, especialmente um que não está vinculado (organizacionalmente) a uma única pessoa.

Concordo, o ioredis é bom, mas não acho que seja uma solução de tamanho único. No que diz respeito à consolidação, achei que o analisador unificado era o principal objetivo já alcançado. Eu nunca considerei que haveria um único módulo completo, apenas dadas as diferenças de sintaxe.

@stockholmux : Meu trabalho (no Redis Labs) apoiaria meu trabalho neste módulo, mas se não pudermos fazer um lançamento do NPM, não faz sentido investir tempo.

Idem também, estamos dispostos a dedicar recursos a isso também @invertase , mas se não pudermos publicá-lo, também não fará sentido para nós.

@stockholmux : @Salakar você conversou com algum dos outros proprietários do NPM (Matt, Ben ou Bryce)?

Este é um bom ponto, eu não tenho, eu vou entrar em contato com eles em breve.

@stockholmux : Concordo, ioredis é bom, mas não acho que seja uma solução de tamanho único. No que diz respeito à consolidação, achei que o analisador unificado era o principal objetivo já alcançado. Eu nunca considerei que haveria um único módulo completo, apenas dadas as diferenças de sintaxe.

Por interesse, quais são seus requisitos que a redis lib atende, mas ioredis não? Meus requisitos envolviam clustering e sentinela que redis atualmente não suporta, exceto por alguns pacotes de terceiros, alguns dos quais também foram abandonados.

Talvez os protocolos de conexão subjacentes entre as duas bibliotecas também possam ser compartilhados, então é apenas como você interage com cada um que é diferente?

@Salakar Eu gosto da abordagem modular do sentinela e do clustering sobre a abordagem monolítica do ioredis (novamente, precisamos lidar com o abandonware). Algumas pessoas precisam disso, outras não. O ecossistema geral do Redis está ficando maior e modular é a maneira de suportar mais sem complexidade, IMHO. Ioredis é uma base de código muito maior (18.897 vs 7.038 linhas de código), o que pode ser mais recursos, mas prefiro não ter muito material extra que não estou usando.

O lugar onde eu acho que o node_redis tem uma grande vantagem é o suporte ao módulo Redis, que é fácil com o node_redis e um pouco chato com o ioredis.

Entrei em contato com @mranney via DMs do Twitter e perguntei se ele poderia conceder a mim e ao proprietário @stockholmux acesso à organização GitHub e aos pacotes NPM, então veremos o que vem disso.

Acho que eu e @stockholmux concordamos que manter e publicar tudo de onde estão atualmente é o melhor caminho a seguir - se pudermos. Se não, acho que podemos procurar alternativas, embora eu prefira não.

Uma pequena sugestão. Talvez você deva considerar migrar o código-fonte para o TypeScript.

Olá a todos, assumi o cargo de mantenedor principal e tenho todo o acesso necessário agora 🎉 muito obrigado a @BridgeAR por todo o trabalho que ele fez (e está fazendo) nesta biblioteca e por me deixar assumir.

Passei os últimos dias preparando o master para um lançamento e, há alguns minutos, acabei de publicar a v3.0.0 no NPM; https://github.com/NodeRedis/node-redis/releases/tag/v3.0.0 - que inclui essa alteração.

Espere lançamentos regulares - minha primeira prioridade no momento é tornar este projeto mais amigável para os contribuidores para garantir que o projeto viva e continue a crescer e não seja bloqueado pelo tempo de nenhuma pessoa singular. Para fazer isso, gostaria de aumentar um conjunto maior de contribuidores superficiais. Com isso espero mitigar o problema anterior do projeto precisar de atualizações mas não havendo ninguém que tenha o poder de fazê-lo. Estou trabalhando com o seguinte sobre isso;

• [x] Contribuição de documentos e Código de Conduta
• [x] Configurar um Open Collective e uma política de despesas de contribuidores
  
  
  
  • Você notará o novo e brilhante botão Sponsor na parte superior do GitHub, eu também fui em frente e patrocinei por mim mesmo e por meio da minha empresa para ajudar a iniciá-lo para futuros colaboradores
  
  
• WIP: Automação de lançamento e versionamento semântico (publicação no NPM, geração de changelogs, etc.)
• [x] Melhorar o CI, por exemplo, o Windows CI é super lento e instável agora

Depois disso, estarei mudando minha atenção para modernizar (por exemplo, promessas, texto datilografado) e limpar a dívida técnica na base de código do Node Redis. @BridgeAR já fez um monte de coisas para isso, se você estiver curioso, confira o branch WIP v4 e seu changelog.

@Salakar Parabéns! Eu queria pegar o trabalho de promessas (adoraria abandonar async-redis ), mas presumo que já esteja feito. Vocês têm alguma ideia de prazo? Você está aceitando contribuições nessa frente (ex.: temos algum tipo de checklist)?

Ei @GCSBOSS , confira o branch 'v4' - é o refatoramento em andamento, que promete suporte, sem eta / timeframe, mas desculpe