Jdbi: Soporta R2DBC

Hola Vaughn, gracias por el puntero. Reactive es muy nuevo y emocionante, pero tengo entendido que la implementación actual de JDBC y, de hecho, el software del servidor de base de datos en sí, lo convierte en un pobre candidato para los conceptos reactivos en las capas inferiores. El servidor de la base de datos tiene procesos de trabajo que toman consultas y producen resultados, y cada proceso trabajará en su consulta hasta su finalización. No es posible enviar 10 consultas de forma asincrónica y esperar sus resultados.

Esto significa que a medida que implementa JDBC reactivo, eventualmente encontrará que debe implementar un grupo de subprocesos de estilo antiguo que contiene sus conexiones / identificadores, consultas de servicios y luego emite resultados en el marco reactivo. Esto significa que puede tener algunos de los beneficios de reactivo, en particular puede escribir código reactivo, pero limita seriamente los beneficios de escalabilidad que los intentos reactivos de lograr.

Así que definitivamente daríamos la bienvenida a las integraciones de API, pero a menos que el estado del mundo JDBC haya avanzado desde la última vez que investigué, será un contenedor algo limitado que solo oculta el hecho de que el código subyacente sigue siendo un código de la vieja escuela.

Agradezco la oferta de ponerse al día en su plataforma, pero nuestra biblioteca se enorgullece de ser casi completamente independiente y no parte de ninguna plataforma o marco. Entonces, si bien podemos buscar inspiración y siempre estamos dispuestos a colaborar hacia objetivos compartidos, somos un proyecto ferozmente independiente :)

¡Hola, Steven! Gracias por tus comentarios. Actualmente resolvemos el reactivo sobre JDBC serializando las solicitudes dentro de los actores en nuestras implementaciones vlingo-symbio . Puede crear tantos JDBCObjectStoreActor como tenga sentido para sus limitaciones de conexión, pero los propios actores acceden a JDBC sincrónicamente. Es más, el cliente de las implementaciones ObjectStore ejecutan en actores no bloquea mientras se cumplen las consultas.

No tengo un conocimiento profundo de R2DBC, pero se promociona como un reemplazo completo de JDBC y funciona de forma completamente asincrónica como controlador de base de datos. Actualmente existen implementaciones solo para Postgres y MS SQL Server, pero probablemente crecerán con el tiempo. Me preguntaba cómo sería para Jdbi implementarlo sobre R2DBC. Entiendo si esto no tiene sentido para usted ahora, pero la referencia está aquí en caso de que lo tenga en el futuro. Sin estrés :)

Interesante, en realidad proporcionan sus propios controladores. ¡Así que tal vez haya algún beneficio aquí!

Tengo curiosidad por explorar esto más a fondo: puntos de referencia, código de prueba de concepto, etc. Parece que hay algunas limitaciones: su controlador r2dbc para postgres anuncia que, por ejemplo, los tipos BLOB y CLOB no funciona todavía, y no se mencionan en absoluto los procedimientos almacenados o CALL .

Pero al menos mi enfoque personal en este momento está en otra parte, por lo que esto puede necesitar alguna aportación y atención de la comunidad para avanzar, ya que no tengo tiempo en este momento para abrir una exploración aquí, y no creo que otros miembros principales estén buscando saltar sobre él tampoco.

Espero escuchar más, incluso si solo votan otros miembros de la comunidad que esta es una característica necesaria.

Genial ver este boleto.

Quería descartar rápidamente dos cosas para aclarar el estado de R2DBC:

• Todavía es una iniciativa joven y cosas como BLOB / CLOB y el soporte de procedimientos almacenados deben implementarse antes de pasar a GA.
• Los controladores son completamente reactivos y no bloquean, lo que significa que toda la parte de E / S no bloquea. No se puede descargar el trabajo de bloqueo en grupos de subprocesos.

En cualquier caso, R2DBC tiene como objetivo que un SPI sea recogido por implementaciones de cliente como Spring Data R2DBC, R2DBC Client (una pequeña envoltura en la parte superior de R2DBC SPI que presta algunas ideas de jdbi) y más por venir.

Solo quería intervenir y mencionar que mi capa de cliente de demostración / prototipo original, r2dbc-client fue diseñada en base a las API y el espíritu de Jdbi. Si decide investigar más a fondo, creo que le resultará familiar 😄.

He visto a gente exponer cosas de Rx de JDBI ( @hgschmie por ejemplo). No estoy seguro de qué significaría "soporte" para R2DBC.

¿Estás hablando de implementar R2DBC sobre JDBI, hacer que JDBi consuma R2DBC Connection s, intercambiar JDBI para enfocarse en interfaces Rx, o ... algo más?

Creo que sería "admitir controladores R2DBC para ser utilizados por JDBI, exponiendo las interfaces JDBI".

R2DBC es un reemplazo asincrónico de JDBC.

@brianm R2DBC no es JDBC en ThreadPools. R2DBC significa dos cosas:

1. Los controladores R2DBC son implementaciones que utilizan una capa de transporte sin bloqueo que devuelve tipos org.reactivestreams.Publisher para cada operación vinculada a E / S. No usan controladores JDBC debajo, pero implementan protocolos de cable desde cero.
2. R2DBC es un SPI estandarizado (independiente del proveedor) que permite construir bibliotecas cliente en la parte superior. Las implementaciones de controladores se pueden intercambiar como se hace hoy para JDBC.

¿Está hablando de implementar R2DBC sobre JDBI, hacer que JDBi consuma conexiones R2DBC?

Sí, esto es lo que básicamente significa. Tener un módulo JDBI específico de R2DBC que devuelva los tipos Project Reactor / RxJava2 / Zerodep.

Estoy bastante seguro de que entiendo lo que es R2DBC, y creo que es algo muy bueno.

¡Estoy tratando de averiguar qué es el "soporte JDBI"!

¿Quizás escribir una muestra de código de lo que espera hacer a través de la API de JDBI?

¿Qué tal si apoya lo siguiente para empezar?

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 -> { … });

El soporte basado en interfaz podría verse así:

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();
}

No tengo opiniones sobre RxJava vs. Project Reactor, por lo tanto, traté de enumerar variantes usando ambas API.

¿Alguien podría aclarar qué es exactamente lo que se propone aquí?

¿R2DBC es una capa sobre JDBC o es algo propio? Porque Jdbi está acoplado a JDBC en extremo.

R2DBC no es una capa sobre JDBC. R2DBC es una API sin bloqueo para acceder a bases de datos SQL y es algo propio (los controladores R2DBC generalmente se escriben desde cero implementando protocolos de cable específicos del proveedor utilizando una capa de E / S sin bloqueo). Si lo desea, R2DBC es la especificación reactiva de cómo integrarse con bases de datos SQL.

La propuesta aquí sería tener una API que se vea y funcione como Jdbi pero use debajo de los controladores R2DBC. En lugar de devolver objetos escalares, la API devolvería tipos de Flujos reactivos.

Gracias por la aclaración. Espero que el primer paso aquí sea crear un prototipo de una bifurcación o rama Jdbi que sirva mínimamente como PoC que muestre cómo implementar los ejemplos anteriores sobre R2DBC. A partir de ahí, tendríamos que determinar un camino hacia la integración en paralelo al soporte JDBC existente, o establecer que sería mejor como un hard fork. Como Matthew señala anteriormente, actualmente estamos estrechamente vinculados a JDBC y es probable que el cambio sea mucho trabajo duro y que potencialmente requiera cambios importantes.

Estoy emocionado de tener esto en el radar a largo plazo del proyecto, pero no espero que se mueva rápidamente sin una participación significativa de la comunidad.

@stevenschlansker Hemos creado inicialmente r2dbc-client que se inspiró en JDBI. ¿Qué opinas sobre una solicitud de extracción / PoC que introduce un módulo r2dbc ( jdbi-r2dbc ) como una contribución del cliente R2DBC de vuelta a JDBI en las líneas 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);

Muy genial. Sí, si el trabajo se puede integrar de una manera razonablemente fluida, ¡con gusto lo incubaríamos en un módulo!

Sería bueno si de alguna manera la Rdbi api "viniera de" Jdbi - en eso cuando haces un jdbi.installPlugin(...).registerRowMapper(...) entonces cualquier Rdbi instancias que "vengan de "que Jdbi también obtienen su configuración. También sería bueno poder hacer cosas como <strong i="11">@SqlUpdate</strong> CompletableFuture<ResultType> doSomeWork(...); o cualquier tipo de reactivo apropiado.