1085 ZADD와 같은 명령에 대한 NX/XX 플래그 지원을 지원합니까?

몇 달이 지났는데 이 전면에 업데이트된 타임라인이 있습니까?

+1

클러스터/샤딩 지원이 곧 제공될 가능성이 있습니까? AWS는 ElastiCache에 대한 redis 클러스터 지원을 가지고 있으며 이를 사용하고 싶지만 이 라이브러리가 실제로 실행 가능하려면 해당 기능 세트를 따라잡아야 합니다.

이 문제는 IMHO에 고정되어야 합니다.

또한 https://github.com/gosquared/redis-clustr 이 클러스터 지원에 충분한 솔루션이 될 수 있습니까?

센티넬에 대한 동등한 래퍼는 훌륭할 것입니다. https://www.npmjs.com/package/redis-sentinel 일 수도 있지만 죽은 것처럼 보입니다(마지막 게시 이후 4년).

아마도 우리는 여기에서 이 저장소의 미래에 대해 논의해야 할 것입니다. 이 패키지의 NPM에 대한 마지막 게시는 2년이 넘었으며 거의 ​​2년 동안 NPM에 게시되지 않은 마스터에 대한 수정 사항이 있습니다(예: https://github.com/NodeRedis/node_redis/issues/1331;

이것은 내가 @BridgeAR 에 대해 불평하는 것이 아니라 @nodejs 에서 실제로 훌륭한 일을 하고 있다는 점에 유의하십시오. 따라서 이 리포지토리에 대한 그의 시간은 당연히 제한됩니다.

유지 관리 부담을 기꺼이 감수하고 싶지만 기존 저장소에서 NPM 게시 액세스를 사용할 수 없다는 점을 감안할 때 이에 대해 우리가 취할 수 있는 조치에 대해 생각하고 싶습니다(몇 년 동안 여러 번 요청했습니다) .

현재로서는 액세스 권한을 얻지 않는 한 포크하고 다시 시작하는 것이 유일한 옵션인 것 같습니다.

@Salakar 또한 이 패키지를 발전시키는 데 도움을 줄 의향이 있습니다. 왜 NPM 패키지 이름을 포기해야 하는지 잘 모르겠습니다('redis'는 강력합니다). @BridgeAR 이 NPM 패키지를 제어하지 않으며 이것을 누군가에게 전송해야 합니까? 몇 달 동안 거의 조치가 없었고 솔직히 말해서 그냥 가만히 앉아 있는 논리가 잘 이해되지 않습니다.

나는 우리가 이 패키지를 더 이상 사용하지 않아야 한다고 생각하지 않습니다. 이것은 최신 상태로 유지될 수 있는 좋은 코드베이스이며 수많은 다른 패키지가 이에 의존합니다.

내가 표면화하고 싶은 또 다른 것은 상당한 변경이 필요한 다가오는 RESP3/Redis 6 변경 사항입니다. 지원하기 쉬워야 하는 Redis 6의 ACL 기능을 살펴보았지만 node_redis에 대한 심각한 리팩토링이 필요합니다. Redis Labs에서 제 직업은 이 모듈에 대한 제 작업을 지원하지만 NPM 릴리스를 할 수 없다면 시간을 투자하는 것은 의미가 없습니다.

@BridgeAR 이 NPM 패키지를 제어하지 않으며 이것을 누군가에게 전송해야 합니까? 몇 달 동안 거의 조치가 없었고 솔직히 말해서 그냥 가만히 앉아 있는 논리가 잘 이해되지 않습니다.

맞습니다. 하지만 2018년 2월부터 NPM 게시 액세스를 요청했고 2019년 2월에 다시 요청했고 가장 최근의 요청은 2019년 9월에 요청했습니다. 답변을 받았지만 NPM 게시 액세스를 요청하는 주제에 대해서는 없었습니다 🤷‍♂. https://github.com/NodeRedis/node_redis/issues/1402#issuecomment -490273744 의도를 나타낼 수 있습니까?

이전이 이루어지지 않을 경우 계속 진행할 수 있도록 명확히 해야 한다고 생각합니다.

예를 들어 ioredis는 정말 훌륭하고 예전에 라이브러리 통합에 대한 이야기가 있었습니다(저는 새로운 파서, denque lib, 클러스터 키 슬롯 calc 등과 같은 기본 도구에 대해 작업했습니다): https:// github.com/NodeRedis/node_redis#consolidation -its-time-for-celebration - 여전히 장기적인 목표가 되어야 한다고 생각합니까?

주제에서 벗어났지만 얼마 전에 새 클라이언트를 구축하는 실험을 시작했습니다. https://twitter.com/mikediarmid/status/1074240036936318976 - 하지만 다시 시작하거나 통합을 돕기 위해 중단했습니다.

그것도 루트일지도 🤷‍♂

@Salakar 다른 NPM 소유자(Matt, Ben 또는 Bryce)와 이야기를 나눈 적이 있습니까? Ruben이 MIA라면 프로젝트를 진행하려면 한 사람이 걸림돌이 되어서는 안 된다고 생각합니다. 이런 종류의 문제가 왜 이런 식으로 설정되었는지 추측합니다. 오픈 소스 프로젝트, 특히 한 사람에게 (조직적으로) 묶여 있지 않은 프로젝트에 대한 1402 문제에 대한 의견을 찾았습니다.

동의합니다. ioredis가 좋지만 모든 솔루션에 적합한 단일 크기는 아니라고 생각합니다. 통합에 관해서는 통합 파서가 이미 달성된 주요 목표라고 생각했습니다. 구문의 차이만 고려하면 완전히 단일 모듈이 있을 거라고는 생각하지 못했습니다.

@stockholmux : Redis Labs에서 내 직업은 이 모듈에 대한 내 작업을 지원하지만 NPM 릴리스를 할 수 없다면 시간을 투자하는 것은 의미가 없습니다.

마찬가지로 @invertase 에도 리소스를 바칠 의향이 있지만, 이를 게시할 수 없다면 우리에게도 의미가 없습니다.

@stockholmux : @Salakar 다른 NPM 소유자(Matt, Ben 또는 Bryce)와 이야기를 나눈 적이 있습니까?

이것은 좋은 점입니다. 저는 그렇지 않습니다. 곧 그들에게 연락할 것입니다.

@stockholmux : 동의합니다. ioredis가 좋긴 하지만 모든 솔루션에 딱 맞는 사이즈는 아니라고 생각합니다. 통합에 관해서는 통합 파서가 이미 달성된 주요 목표라고 생각했습니다. 구문의 차이만 고려하면 완전히 단일 모듈이 있을 거라고는 생각하지 못했습니다.

redis lib가 충족하지만 ioredis 가 충족하지 않는 요구 사항은 무엇입니까? 내 요구 사항에는 redis 가 현재 지원하지 않는 클러스터링 및 센티넬이 포함되어 있지만 일부 타사 패키지도 포기되었습니다.

아마도 두 라이브러리 사이의 기본 연결 프로토콜도 공유될 수 있으며, 그렇다면 순전히 서로 다른 인터페이스와 인터페이스하는 방법은 무엇입니까?

@Salakar 나는 ioredis의 모놀리식 접근 방식보다 센티넬 및 클러스터링에 대한 모듈식 접근 방식을 좋아합니다(다시 말하지만, 포기웨어를 처리해야 함). 어떤 사람들은 이것이 필요하고 다른 사람들은 필요하지 않습니다. 전체 Redis 생태계는 점점 더 커지고 있고 모듈화는 복잡성 없이 더 많은 것을 지원하는 방식인 IMHO입니다. Ioredis는 더 많은 기능을 제공할 수 있는 코드베이스(18,897 대 7,038 코드 줄)보다 훨씬 큽니다.

node_redis가 큰 장점이라고 생각하는 곳은 Redis 모듈 지원입니다. node_redis에서는 쉽고 ioredis에서는 고통스럽습니다.

저는 Twitter DM을 통해 @mranney 에게 연락하여 GitHub org 및 NPM 패키지에 대한 액세스 권한을 저와 @stockholmux 소유자 모두에게 부여할 수 있는지 물었습니다.

제 생각에는 저와 @stockholmux 가 현재 있는 모든 것을 유지 관리하고 게시하는 것이 최선의 방법이라는 데 동의한다고 생각합니다. 그렇지 않다면 대안을 찾아볼 수 있을 것 같지만 그렇지 않습니다.

작은 제안. 소스 코드를 TypeScript로 마이그레이션하는 것을 고려해야 할 수도 있습니다.

안녕하세요 여러분, 저는 수석 유지 관리자를 맡았고 이제 필요한 모든 액세스 권한을 갖게 되었습니다. 🎉 이 라이브러리에서 그가 이 라이브러리에서 수행한 모든 작업(및 현재 하고 있는)과 제가 인계받을 수 있게 해준 @BridgeAR 에 큰 감사를 드립니다.

지난 며칠 동안 릴리스를 위한 마스터 준비를 했으며 몇 분 전 NPM에 v3.0.0을 게시했습니다. https://github.com/NodeRedis/node-redis/releases/tag/v3.0.0 - 이 변경 사항을 포함합니다.

정기 릴리스를 기대하십시오 - 현재 나의 최우선 과제는 프로젝트가 살아 있고 계속해서 성장하고 한 사람의 시간에 의해 방해받지 않도록 이 프로젝트를 기여자 친화적으로 만드는 것입니다. 이렇게 하기 위해 더 많은 얕은 기여자들을 키우고 싶습니다. 이를 통해 업데이트가 필요한 프로젝트의 이전 문제를 완화하기를 희망하지만 업데이트할 권한이 있는 사람이 없습니다. 나는 이것에 대해 다음을 통해 일하고 있습니다.

• [x] 기여 문서 및 행동 강령
• [x] Open Collective 및 기부자 비용 정책 설정
  
  
  
  • GitHub 상단에 반짝이는 새로운 Sponsor 버튼이 있는 것을 알 수 있을 것입니다. 저는 또한 미래 기여자를 위해 시작하는 데 도움을 주기 위해 직접 후원하고 회사를 통해 후원했습니다.
  
  
• WIP: 릴리스 자동화 및 시맨틱 버전 관리(NPM에 게시, 변경 로그 생성 등)
• [x] CI 개선(예: Windows CI는 현재 매우 느리고 불안정합니다.

그 후에는 Node Redis 코드베이스에서 현대화(예: 약속, 타이프스크립트) 및 기술적 부채 청산으로 관심을 전환할 것입니다. @BridgeAR 은 이미 이를 위해 많은 작업을 수행했습니다. 궁금한 점이 있으면 WIP v4 분기 와 해당 변경 로그를 확인하세요.

@Salakar 축하합니다! 나는 약속 작업을 선택하고 싶었지만 ( async-redis 를 버리고 싶습니다 ) 하지만 지금쯤에는 대부분 완료되었다고 가정합니다. 기간에 대해 알고 계신가요? 그 면에서 기여를 수락하고 있습니까(예: 일종의 체크리스트가 있습니까)?

@GCSBOSS님 , 'v4' 브랜치를 확인하세요. 진행 중인 리팩터링으로, 약속을 지원하고, 예상 시간은 없지만 죄송합니다.