Predis: Promessas e futuros para dutos Predis

Estou finalmente testando com o código real uma nova abordagem para os internos da abstração do pipeline na v2.0 usando geradores (yay para descartar versões antigas do PHP!) E em meus vários testes para verificar se o novo design é realmente prático e consistente (enquanto fornece mais flexibilidade do que antes) Eu também tentei emular a ideia básica por trás de Deferred e no final eu acho, a menos que eu tenha perdido algo ao longo do caminho, que algo como Deferred poderia ser realmente conectado ao novo design facilmente estendendo a classe Pipeline de base ( sim, teremos apenas na aula) e substituir 2 ou 3 métodos. Digo "emular" porque não usei promessas / futuros para manter meu teste simples, não tenho tempo no caixa eletrônico, vou tentar nos próximos dias ou talvez deixo para você assim que eu ' Vou empurrar um rascunho de PR 😉

Tudo bem, estou provisoriamente adicionando este recurso para v2.0, pelo menos para pipelines. Para ser honesto, ainda não posso dizer para transações simples, idealmente Predis\Transaction\MultiExec deveria ser reimplementado do zero com base em um design interno semelhante ao que eu imaginei para pipelines, isso é o que eu planejava fazer de qualquer maneira então veremos.

Por enquanto, estou almejando uma abordagem mais leve em comparação com Deferred (sem reduce() , sem valores brutos, ...) mas há suporte para binding, listeners e trasformers. Teremos Predis\Pipeline\DeferredPipeline retornando Predis\Response\FutureResponse instâncias. DeferredPipeline::execute() não retornará nada, os valores lidos do pipeline serão acessíveis apenas por FutureResponse . Idealmente, DeferredPipeline deve ser facilmente extensível por terceiros para que eles possam conectar qualquer wrapper de resposta ou lógica para preencher os valores. Deve ser possível reescrever a biblioteca adiada completa em cima disso.

Minha implementação proposta seguirá em alguns dias.

Apenas um aviso: estou atrasado em meus planos porque estava ocupado na semana passada e levará mais alguns dias, no entanto, enquanto estou adicionando os últimos retoques e polindo o código para pipelines (quase pronto para enviar um rascunho de PR mas ainda faltam testes, pois vão exigir muito tempo e trabalho) Comecei a experimentar com transações e, neste ponto, acho que realmente será possível compartilhar a mesma abordagem, então provavelmente teremos um Predis\Transaction\DeferredMultiExec retornando Predis\Response\FutureResponse instâncias.

A propósito, Predis\Transaction\MultiExec reutilizará um novo componente subjacente criado para pipelines, o que significa que as transações serão encaminhadas internamente (fora das operações de verificar e definir, obviamente), assim como acontece com pipelines atômicos. Ter duas abstrações separadas ainda faz sentido para mim, pois elas têm algumas diferenças importantes.

A nova abstração do pipeline está no ar em # 663.

Vou postar uma essência com minha prova de conceito para Predis\Pipeline\DeferredPipeline amanhã (um PR real e mais curado virá quando # 663 será considerado estável o suficiente em termos de código e design interno), mas pelo menos podemos começar a brincar com as coisas e ver até onde podemos ir.

Ainda tenho que encontrar alguns fundamentos comuns entre pipelines e transações para compartilhar algumas exceções, especialmente no caso de transações abortadas, e tornar ambos verdadeiramente intercambiáveis ​​(como discutimos em outras questões / pr), mas acho que isso só será possível quando realmente comece a reimplementar as transações (eu tenho uma filial local, mas é uma bagunça e incompleta, então não conta ainda).

Acabei de postar minha prova de conceito nesta essência , veja também o arquivo README incluso. Está longe de ser definitivo, mas é pelo menos um ponto de partida. Evitei um repositório completo porque só queria compartilhar o código e dar a todos uma ideia do que estou planejando. Idealmente, isso se tornará um PR adequado no futuro. Vou manter a essência atualizada se alterações importantes forem enviadas no branch de desenvolvimento monitorado por # 663.

Peço desculpas por não ter tido a chance de estudar sua essência mais cedo. Estou feliz em ver que a maioria dos recursos que implementei em Deferred estão presentes em sua prova de conceito.

Pela minha olhada casual, não sei por que asArray() e asGenerator() requerem um tratamento especial. Eles não poderiam simplesmente se registrar como transformadores diretamente, em vez de definir sinalizadores internos e adicioná-los durante a finalização? Ou você está tentando impor um pedido de transformador (onde eles sempre vão por último)? Só pensando em simplicidade aqui.