Jdbi: Suporte R2DBC

Oi Vaughn, obrigado pelo ponteiro. Reativo é muito novo e empolgante, mas meu entendimento é que a implementação atual de JDBC, e de fato o próprio software de servidor de banco de dados, o torna um candidato fraco para conceitos reativos nas camadas inferiores. O servidor de banco de dados possui processos de trabalho que realizam consultas e produzem resultados, e cada processo trabalhará em sua consulta até a conclusão. Não há capacidade de enviar 10 consultas de maneira assíncrona e aguardar seus resultados.

Isso significa que, conforme você implementa JDBC reativo, eventualmente descobre que deve implementar um pool de threads de estilo antigo que mantém suas conexões / identificadores, consultas de serviços e, em seguida, emite os resultados para a estrutura reativa. Isso significa que você pode ter alguns dos benefícios do reativo, em particular, você pode escrever código reativo, mas limita seriamente os benefícios de escalabilidade que o reativo tenta alcançar.

Portanto, com certeza gostaríamos de receber integrações de API, mas a menos que o estado do mundo JDBC tenha mudado desde a última investigação, será um invólucro um tanto limitado que apenas esconde o fato de que o código por baixo ainda é um código encadeado da velha escola.

Agradeço a oferta de acelerar sua plataforma, mas nossa biblioteca se orgulha de ser quase totalmente autônoma e não fazer parte de nenhuma plataforma ou estrutura. Portanto, embora possamos buscar inspiração e estar sempre dispostos a colaborar para objetivos comuns, somos um projeto ferozmente independente :)

Ei, Steven! Obrigado por seus comentários. Atualmente, resolvemos o JDBC reativo ao serializar solicitações dentro dos atores em nossas implementações de vlingo-symbio . Você pode criar tantos JDBCObjectStoreActor quanto fizer sentido para suas limitações de conexão, mas os próprios atores acessam JDBC de forma síncrona. É mais que o cliente das implementações de ObjectStore execução nos atores não bloqueiam enquanto as consultas estão sendo atendidas.

Não tenho um conhecimento completo do R2DBC, mas ele é apresentado como um substituto completo do JDBC e funciona de forma totalmente assíncrona como um driver de banco de dados. Atualmente, existem implementações apenas para Postgres e MS SQL Server, mas provavelmente irão crescer com o tempo. Eu estava me perguntando como seria para o Jdbi implementar no R2DBC. Eu entendo se isso não faz sentido para você agora, mas a referência está aqui para o caso de isso acontecer em algum momento futuro. Sem estresse :)

Interessante, eles realmente fornecem seus próprios drivers. Portanto, talvez haja algum benefício a ser obtido aqui!

Estou curioso para explorar isso mais: benchmarks, código de prova de conceito, etc. Parece haver algumas limitações: seu driver r2dbc para postgres anuncia que, por exemplo, os tipos BLOB e CLOB não funcionam ainda, e não há nenhuma menção de procedimentos armazenados ou CALL .

Mas pelo menos meu foco pessoal agora está em outro lugar, então isso pode precisar de alguma contribuição e atenção da comunidade para seguir em frente, já que não tenho tempo agora para abrir uma exploração aqui, e não imagino que outros membros centrais estejam olhando para pule nele também.

Estou ansioso para ouvir mais, mesmo que apenas votos de outros membros da comunidade, que este é um recurso necessário.

Ótimo ver este ingresso.

Eu queria deixar de lado duas coisas para esclarecer o estado de R2DBC:

• Ainda é uma iniciativa jovem e coisas como BLOB / CLOB e suporte a Stored Procedure devem ser implementadas antes de partirmos para GA.
• Os drivers são totalmente reativos e não bloqueiam, o que significa que toda a parte de E / S não bloqueia. Não há transferência de trabalho de bloqueio para pools de threads.

Em qualquer caso, o R2DBC visa que um SPI seja captado por implementações de cliente, como Spring Data R2DBC, R2DBC Client (um pequeno invólucro no topo do R2DBC SPI que empresta algumas idéias do jdbi) e mais por vir.

Só queria entrar na conversa e mencionar que minha camada de cliente de protótipo / demonstração original, r2dbc-client foi projetada com base nas APIs e no ethos do Jdbi. Se você decidir investigar mais, acho que você achará familiar 😄.

Eu vi pessoas expor coisas Rx fora do JDBI ( @hgschmie por exemplo). Não tenho certeza do que significa "suporte" para R2DBC.

Você está falando sobre implementar R2DBC em cima de JDBI, fazer com que JDBi consuma R2DBC Connection s, trocar JDBI para focar em interfaces Rx ou ... algo mais?

Eu acho que seria "suportar drivers R2DBC a serem usados ​​pelo JDBI, expondo as interfaces JDBI"?

R2DBC é um substituto assíncrono para JDBC.

@brianm R2DBC não é JDBC em ThreadPools. R2DBC significa duas coisas:

1. Os drivers R2DBC são implementações que usam uma camada de transporte sem bloqueio que retorna org.reactivestreams.Publisher tipos para cada operação ligada a E / S. Eles não usam drivers JDBC por baixo, mas implementam protocolos de conexão a partir do zero.
2. R2DBC é um SPI padronizado (independente do fornecedor) que permite construir bibliotecas de cliente no topo. As implementações de driver podem ser trocadas como é feito hoje para JDBC.

Você está falando sobre a implementação de R2DBC em cima de JDBI, tendo JDBi consumindo conexões R2DBC

Sim, isso é o que basicamente significa. Ter um módulo JDBI específico de R2DBC retornando os tipos Project Reactor / RxJava2 / Zerodep.

Tenho quase certeza de que entendi o que é R2DBC e acho que é uma coisa muito boa.

Estou tentando descobrir o que é "suporte JDBI" para ele!

Talvez escrever um exemplo de código do que você espera fazer por meio da API do JDBI?

Que tal apoiar o seguinte para começar:

Jdbi jdbi = Jdbi.create("r2dbc:h2:mem:///test"); // (H2 in-memory database), obtain ConnectionFactory via ConnectionFactories.get(String url)

// Reactor style:
Flux<User> users = jdbi.withHandle(handle -> {

    return handle.execute("CREATE TABLE user (id INTEGER PRIMARY KEY, name VARCHAR)")

        .then(handle.execute("INSERT INTO user(id, name) VALUES (?0, ?1)", 0, "Alice"))

        .then(handle.createUpdate("INSERT INTO user(id, name) VALUES (?0, ?1)")
            .bind(0, 1)
            .bind(1, "Bob")
            .execute())
         .then(handle.createQuery("SELECT * FROM user ORDER BY name")
              .mapToBean(User.class).many());
});

// RxJava style
Flowable<User> users = jdbi.withHandle(handle -> { … });

O suporte baseado em interface pode ser semelhante a:

public interface UserDao {
    @SqlUpdate("CREATE TABLE user (id INTEGER PRIMARY KEY, name VARCHAR)")
    Completable createTableRxJava();

    @SqlUpdate("CREATE TABLE user (id INTEGER PRIMARY KEY, name VARCHAR)")
    Mono<Void> createTableProjectReactor();

    @SqlQuery("SELECT * FROM user ORDER BY name")
    @RegisterBeanMapper(User.class)
    Flowable<User> listUsersRxJava();

    @SqlQuery("SELECT * FROM user ORDER BY name")
    @RegisterBeanMapper(User.class)
    Flux<User> listUsersProjectReactor();
}

Não tenho opinião formada sobre RxJava versus Project Reactor, portanto, tentei listar variantes usando ambas as APIs.

Alguém poderia esclarecer o que exatamente está sendo proposto aqui?

O R2DBC é uma camada acima do JDBC ou é algo próprio? Porque Jdbi é acoplado ao JDBC ao extremo.

R2DBC não é uma camada acima do JDBC. R2DBC é uma API sem bloqueio para acessar bancos de dados SQL e é sua própria (os drivers R2DBC são normalmente escritos do zero, implementando protocolos de conexão específicos do fornecedor usando uma camada de E / S sem bloqueio). Se você quiser, R2DBC é a especificação reativa de como se integrar com bancos de dados SQL.

A proposta aqui seria ter uma API que se parecesse e funcionasse como Jdbi, mas usasse drivers R2DBC por baixo. Em vez de retornar objetos escalares, a API retornaria tipos de Streams reativos.

Obrigado pelo esclarecimento. Espero que a primeira etapa aqui seja criar um protótipo de um fork ou branch Jdbi que sirva minimamente como um PoC, mostrando como implementar os exemplos acima no topo do R2DBC. A partir daí, teríamos que determinar um caminho para a integração em paralelo ao suporte JDBC existente ou estabelecer que seria melhor como um hard fork. Como Matthew apontou acima, estamos fortemente acoplados ao JDBC atualmente e mudar isso provavelmente exigirá muito trabalho árduo, além de exigir mudanças significativas.

Estou animado por ter isso no radar de longo prazo do projeto, mas não espero que avance rapidamente sem um envolvimento significativo da comunidade.

@stevenschlansker Criamos inicialmente o cliente r2dbc que foi inspirado pelo JDBI. O que você acha de uma solicitação pull / PoC que introduz um módulo r2dbc ( jdbi-r2dbc ) como uma contribuição do Cliente R2DBC de volta ao JDBI ao longo das linhas de:

ConnectionFactory cf = …;

Rdbi rdbi = new Rdbi(cf);

rdbi.inTransaction(handle ->
    handle.execute("INSERT INTO test VALUES ($1)", 100))

    .thenMany(rdbi.inTransaction(handle ->
        handle.select("SELECT value FROM test")
            .mapResult(result -> result.map((row, rowMetadata) -> row.get("value", Integer.class)))))

    .subscribe(System.out::println);

Muito legal. Sim, se o trabalho puder ser integrado de uma forma razoavelmente contínua, ficaríamos felizes em incubá-lo em um módulo!

Seria bom se de alguma forma a Rdbi api "viesse de" Jdbi - quando você fizer um jdbi.installPlugin(...).registerRowMapper(...) então qualquer Rdbi instâncias que "venham daquele Jdbi também obtém sua configuração. Também seria bom poder fazer coisas como <strong i="11">@SqlUpdate</strong> CompletableFuture<ResultType> doSomeWork(...); ou qualquer que seja o tipo reativo apropriado.