Jdbi: Prise en charge de R2DBC

Salut Vaughn, merci pour le pointeur. Reactive est très nouveau et passionnant, mais je crois comprendre que la mise en œuvre actuelle de JDBC, et en fait le logiciel de serveur de base de données lui-même, en fait un mauvais candidat pour les concepts réactifs aux couches inférieures. Le serveur de base de données a des processus de travail qui prennent les requêtes et produisent des résultats, et chaque processus travaillera sur sa requête jusqu'à la fin. Il n'est pas possible de soumettre 10 requêtes de manière asynchrone et d'attendre leurs résultats.

Cela signifie que lorsque vous implémentez JDBC réactif, vous finirez par découvrir que vous devez implémenter un pool de threads de style ancien qui contient vos connexions / descripteurs, vos requêtes de services, puis émet des résultats dans le framework réactif. Cela signifie que vous pouvez bénéficier de certains des avantages du réactif, en particulier que vous pouvez écrire du code réactif, mais cela limite sérieusement les avantages d'évolutivité que le réactif tente d'atteindre.

Nous serions donc très heureux d'accueillir les intégrations d'API, mais à moins que l'état du monde JDBC n'ait évolué depuis ma dernière enquête, il s'agira d'un wrapper quelque peu limité qui masquera simplement le fait que le code sous-jacent est toujours du code fileté à l'ancienne.

J'apprécie l'offre de se mettre à jour sur votre plate-forme, mais notre bibliothèque se targue d'être presque entièrement autonome et de ne faire partie d'aucune plate-forme ou cadre. Ainsi, même si nous cherchons de l'inspiration et sommes toujours prêts à collaborer vers des objectifs communs, nous sommes un projet farouchement indépendant :)

Hé, Steven ! Merci pour vos commentaires. Actuellement, nous résolvons le réactif sur JDBC en sérialisant les requêtes au sein des acteurs dans nos implémentations vlingo-symbio . Vous pouvez créer autant de JDBCObjectStoreActor que cela a de sens pour vos limitations de connexion, mais les acteurs eux-mêmes accèdent à JDBC de manière synchrone. C'est plus que le client des implémentations ObjectStore s'exécutant sur les acteurs ne bloque pas pendant que les requêtes sont exécutées.

Je n'ai pas une compréhension approfondie de R2DBC, mais il est présenté comme un remplacement complet de JDBC et fonctionne de manière totalement asynchrone en tant que pilote de base de données. Il existe actuellement des implémentations pour Postgres et MS SQL Server uniquement, mais elles augmenteront probablement avec le temps. Je me demandais à quoi ressemblerait Jdbi à implémenter sur R2DBC. Je comprends si cela n'a pas de sens pour vous maintenant, mais la référence est ici au cas où ce serait le cas dans le futur. Pas de stress :)

Intéressant, ils fournissent en fait leurs propres chauffeurs. Alors peut-être y a-t-il un avantage à avoir ici !

Je suis curieux d'explorer cela plus en détail : benchmarks, code de preuve de concept, etc. Il semble y avoir certaines limitations : leur pilote r2dbc pour postgres annonce que, par exemple, les types BLOB et CLOB ne le font pas fonctionnent encore, et il n'y a aucune mention des procédures stockées ou CALL .

Mais au moins, mon objectif personnel en ce moment est ailleurs, donc cela peut nécessiter une contribution et une attention de la communauté pour aller de l'avant, car je n'ai pas le temps pour le moment d'ouvrir une exploration ici, et je n'imagine pas que d'autres membres principaux cherchent à sauter dessus non plus.

J'ai hâte d'en savoir plus, même si les autres membres de la communauté votent simplement pour dire qu'il s'agit d'une fonctionnalité nécessaire.

Super de voir ce billet.

Je voulais laisser tomber rapidement deux choses pour clarifier l'état de R2DBC :

• C'est encore une jeune initiative et des choses comme BLOB/CLOB et la prise en charge des procédures stockées doivent être mises en œuvre avant de passer à l'AG.
• Les pilotes sont entièrement réactifs et non bloquants, ce qui signifie que toute la partie E/S est non bloquante. Il n'y a pas de déchargement du travail de blocage dans les pools de threads.

Dans tous les cas, R2DBC vise à ce qu'un SPI soit récupéré par des implémentations clientes telles que Spring Data R2DBC, R2DBC Client (un petit wrapper au-dessus de R2DBC SPI qui prête quelques idées de jdbi) et plus à venir.

Je voulais juste intervenir et mentionner que ma couche cliente prototype/démonstration originale, r2dbc-client été conçue sur la base des API et de la philosophie de Jdbi. Si vous choisissez d'approfondir vos recherches, je pense que vous le trouverez familier .

J'ai vu des gens exposer des trucs Rx hors de JDBI ( @hgschmie par exemple ). Je ne suis pas sûr de ce que signifierait "support" pour R2DBC.

Parlez-vous d'implémenter R2DBC au-dessus de JDBI, de faire en sorte que JDBi consomme R2DBC Connection s, d'échanger JDBI pour se concentrer sur les interfaces Rx, ou... autre chose ?

Je pense que ce serait "supporter les pilotes R2DBC à utiliser par JDBI, exposant les interfaces JDBI" ?

R2DBC est un remplacement asynchrone de JDBC.

@brianm R2DBC n'est pas JDBC sur ThreadPools. R2DBC signifie deux choses :

1. Les pilotes R2DBC sont des implémentations utilisant une couche de transport non bloquante renvoyant des types org.reactivestreams.Publisher pour chaque opération liée aux E/S. Ils n'utilisent pas de pilotes JDBC en dessous mais implémentent des protocoles filaires à partir de zéro.
2. R2DBC est un SPI standardisé (indépendant du fournisseur) permettant de construire des bibliothèques clientes par-dessus. Les implémentations de pilotes peuvent être échangées comme c'est le cas aujourd'hui pour JDBC.

Parlez-vous de la mise en œuvre de R2DBC au-dessus de JDBI, en faisant en sorte que JDBi consomme des connexions R2DBC

Oui, c'est ce que cela signifie essentiellement. Avoir un module JDBI spécifique à R2DBC renvoyant les types Project Reactor/RxJava2/Zerodep.

Je suis à peu près sûr de comprendre ce qu'est R2DBC, et je pense que c'est une très bonne chose.

J'essaie de comprendre en quoi consiste le "support JDBI" !

Peut-être écrire un exemple de code de ce que vous comptez faire via l'API de JDBI ?

Que diriez-vous de prendre en charge les éléments suivants pour commencer :

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

La prise en charge basée sur l'interface pourrait ressembler à :

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

Je ne suis pas convaincu par RxJava vs Project Reactor, j'ai donc essayé de répertorier les variantes utilisant les deux API.

Quelqu'un pourrait-il préciser ce qui est exactement proposé ici?

R2DBC est-il une couche au-dessus de JDBC, ou son propre truc ? Parce que Jdbi est couplé à JDBC à l'extrême.

R2DBC n'est pas une couche au-dessus de JDBC. R2DBC est une API non bloquante pour accéder aux bases de données SQL et c'est sa propre chose (les pilotes R2DBC sont généralement écrits à partir de zéro en implémentant des protocoles filaires spécifiques au fournisseur à l'aide d'une couche d'E/S non bloquante). Si vous voulez, R2DBC est la spécification réactive de la façon d'intégrer les bases de données SQL.

La proposition ici serait d'avoir une API qui ressemble et fonctionne comme Jdbi mais utilise sous les pilotes R2DBC. Au lieu de renvoyer des objets scalaires, l'API renverrait des types de flux réactifs.

Merci pour la clarification. Je m'attends à ce que la première étape ici soit de prototyper un fork ou une branche Jdbi qui sert au minimum de PoC montrant comment implémenter les exemples ci-dessus au-dessus de R2DBC. À partir de là, nous devrons déterminer une voie vers l'intégration en parallèle au support JDBC existant, ou établir qu'il serait préférable en tant que hard fork. Comme Matthew le souligne ci-dessus, nous sommes actuellement étroitement couplés à JDBC et changer cela sera probablement à la fois beaucoup de travail acharné et nécessitera potentiellement des changements de rupture.

Je suis ravi d'avoir cela sur le radar à long terme du projet, mais je ne m'attends pas à ce qu'il évolue rapidement sans une implication significative de la communauté.

@stevenschlansker Nous avons initialement créé r2dbc-client inspiré de JDBI. Que pensez-vous d'une pull request/PoC qui introduit un module r2dbc ( jdbi-r2dbc ) en tant que contribution du client R2DBC dans JDBI comme suit :

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

Très cool. Oui, si le travail peut être intégré d'une manière raisonnablement transparente, nous serions heureux de l'incuber dans un module !

Ce serait bien si l'api Rdbi "provenait de" Jdbi -- en ce sens que lorsque vous faites un jdbi.installPlugin(...).registerRowMapper(...) alors toutes les instances Rdbi qui "viennent from" que Jdbi obtiennent également leur configuration. Ce serait aussi bien de pouvoir faire des choses comme <strong i="11">@SqlUpdate</strong> CompletableFuture<ResultType> doSomeWork(...); ou quel que soit le type réactif approprié.