Predis: Predis 파이프라인에 대한 약속과 미래

마지막으로 생성기를 사용하여 v2.0에서 파이프라인 추상화의 내부에 대한 새로운 접근 방식을 실제 코드로 테스트하고 있으며(이전 PHP 버전을 삭제하는 것이 좋습니다!) 새로운 디자인이 실제로 실용적이고 일관성이 있는지 확인하기 위한 다양한 테스트에서 이전보다 더 유연함) 또한 Deferred의 기본 아이디어를 에뮬레이트하려고 시도했으며 결국에는 중간에 놓친 것이 없는 한 Deferred와 같은 것이 실제로 기본 Pipeline 클래스를 확장하여 새 디자인에 쉽게 연결할 수 있다고 생각합니다. 예, 우리는 클래스에 대해서만 가질 것입니다) 2 또는 3개의 메소드를 재정의합니다. 내가 "에뮬레이트"라고 말하는 이유는 테스트를 간단하게 유지하기 위해 약속/선물을 사용하지 않았기 때문입니다. ATM을 사용할 시간이 없습니다. 앞으로 며칠 내로 시도해 보겠습니다. PR 초안을 푸시합니다 😉

좋습니다. 적어도 파이프라인에 대해서는 v2.0에 대해 이 기능을 잠정적으로 추가하고 있습니다. 솔직히 말해서 아직 일반 거래에 대해서는 말할 수 없습니다. 이상적으로는 Predis\Transaction\MultiExec 가 파이프라인에 대해 구상한 것과 유사한 내부 설계를 기반으로 처음부터 다시 구현해야 합니다. 그래서 우리는 볼 것입니다.

지금은 Deferred ( reduce() 없음, 원시 값 없음, ...)에 비해 더 가벼운 접근 방식을 목표로 하고 있지만 바인딩, 리스너 및 trasformer는 지원됩니다. Predis\Response\FutureResponse 인스턴스를 반환하는 Predis\Pipeline\DeferredPipeline 있습니다. DeferredPipeline::execute() 는 아무 것도 반환하지 않으며 파이프라인에서 읽은 값은 FutureResponse 에서만 액세스할 수 있습니다. 이상적으로 DeferredPipeline 는 타사에서 쉽게 확장할 수 있어야 응답 래퍼나 논리를 연결하여 값을 채울 수 있습니다. 이 위에 본격적인 Deferred 라이브러리를 다시 작성할 수 있어야 합니다.

내가 제안한 구현은 며칠 안에 따를 것입니다.

주의 사항: 지난 주에 바빴기 때문에 계획에 늦었고 며칠 더 걸릴 것입니다. 그럼에도 불구하고 파이프라인에 대한 마지막 수정을 추가하고 코드를 다듬는 동안(PR 초안을 푸시할 준비가 거의 그들은 내가 트랜잭션과 나는 우리가 아마있을 것이다, 그래서이 같은 접근 방식을 공유하고 실제로 가능할 것이라고 생각이 시점에서 실험 시작) 시간과 작업의 톤을 필요로하지만 여전히 테스트 누락 Predis\Transaction\DeferredMultiExec 반환 Predis\Response\FutureResponse 인스턴스.

그런데 Predis\Transaction\MultiExec 는 파이프라인을 위해 생성된 새로운 기본 구성 요소를 재사용할 것입니다. 즉, 원자적 파이프라인에서 발생하는 것처럼 트랜잭션이 내부적으로(확실히 확인 및 설정 작업 외부에서) 파이프라인됩니다. 두 개의 개별 추상화를 갖는 것은 몇 가지 주요 차이점이 있기 때문에 여전히 나에게 의미가 있습니다.

새로운 파이프라인 추상화는 #663에 있습니다.

나는 내일 Predis\Pipeline\DeferredPipeline 대한 개념 증명과 함께 요지를 게시할 예정입니다(#663이 코드와 내부 디자인 모두에서 충분히 안정적인 것으로 간주될 때 실제적이고 더 선별된 PR이 뒤따를 것입니다). 그러나 적어도 우리는 물건을 가지고 놀기 시작하고 우리가 이것을 얼마나 멀리 할 수 ​​있는지 볼 수 있습니다.

나는 여전히 일부 예외를 공유하기 위해 파이프라인과 트랜잭션 사이의 몇 가지 공통 근거를 찾아야 하며, 특히 중단된 트랜잭션의 경우, 둘 다 진정으로 상호 교환 가능하게 만들어야 합니다(다른 문제/pr에서 논의한 것처럼). 그러나 이것은 실제로 한 번만 가능할 것이라고 생각합니다 트랜잭션 재구현을 시작합니다(로컬 브랜치가 있지만 엉망이고 불완전하므로 아직 계산하지 않음).

방금 이 요점 에 대한 개념 증명을 게시했습니다. 포함된 README 파일도 참조하세요. 결정적이지는 않지만 적어도 시작점입니다. 코드를 공유하고 모든 사람에게 내가 계획하는 것에 대한 아이디어를 주고 싶었기 때문에 본격적인 저장소를 피했습니다. 이상적으로는 이것이 적절한 PR이 될 것입니다. 미래. #663에 의해 추적되는 개발 분기에 주요 변경 사항이 푸시되면 요점을 계속 업데이트하겠습니다.

요점을 더 빨리 연구할 기회를 얻지 못한 것에 대해 사과드립니다. Deferred 에서 구현한 대부분의 기능이 귀하의 개념 증명에 표시되어 기쁩니다.

가볍게 살펴보니 asArray() 및 asGenerator() 특별한 대우가 필요한 이유를 모르겠습니다. 내부 플래그를 설정하고 완료 중에 추가하지 않고 단순히 자신을 변환기로 직접 등록할 수 없었습니까? 또는 변환기 순서를 적용하려고 합니까(항상 마지막으로 가는 위치)? 여기에서는 단순함만 생각하면 됩니다.