Jdbi: R2DBC unterstützen

Hallo Vaughn, danke für den Hinweis. Reactive ist sehr neu und aufregend, aber mein Verständnis ist, dass die aktuelle Implementierung von JDBC und tatsächlich die Datenbankserver-Software selbst es zu einem schlechten Kandidaten für reaktive Konzepte auf den unteren Schichten macht. Der Datenbankserver verfügt über Worker-Prozesse, die Abfragen annehmen und Ergebnisse liefern, und jeder Prozess bearbeitet seine Abfrage bis zum Abschluss. Es gibt keine Möglichkeit, 10 Abfragen asynchron zu senden und ihre Ergebnisse abzuwarten.

Dies bedeutet, dass Sie bei der Implementierung von JDBC reaktiv feststellen müssen, dass Sie schließlich einen Thread-Pool im alten Stil implementieren müssen, der Ihre Verbindungen/Handles und Serviceabfragen enthält und dann Ergebnisse an das reaktive Framework ausgibt. Dies bedeutet, dass Sie einige der Vorteile von reaktivem Code nutzen können, insbesondere reaktiven Code schreiben können, aber es schränkt die Skalierbarkeitsvorteile, die mit reaktiven Versuchen erzielt werden, stark ein.

Wir würden uns also definitiv über API-Integrationen freuen, aber wenn sich der Zustand der JDBC-Welt seit meiner letzten Untersuchung nicht geändert hat, wird es ein etwas eingeschränkter Wrapper sein, der nur die Tatsache verbirgt, dass der Code darunter immer noch Threaded-Code der alten Schule ist.

Ich freue mich über das Angebot, Ihre Plattform auf den neuesten Stand zu bringen, aber unsere Bibliothek ist stolz darauf, fast vollständig eigenständig zu sein und nicht Teil einer Plattform oder eines Frameworks zu sein. Während wir also vielleicht nach Inspiration suchen und immer bereit sind, an gemeinsamen Zielen zusammenzuarbeiten, sind wir ein äußerst unabhängiges Projekt :)

He, Steven! Danke für deine Kommentare. Derzeit lösen wir das Reaktiv-über-JDBC, indem wir Anfragen innerhalb von Akteuren in unseren vlingo-symbio Implementierungen serialisieren. Sie können so viele JDBCObjectStoreActor erstellen, wie es für Ihre Verbindungsbeschränkungen sinnvoll ist, aber die Akteure selbst greifen synchron auf JDBC zu. Es ist eher so, dass der Client der ObjectStore Implementierungen, die auf Akteuren ausgeführt werden, nicht blockiert, während Abfragen ausgeführt werden.

Ich habe kein umfassendes Verständnis von R2DBC, aber es wird als vollständiger JDBC-Ersatz angepriesen und funktioniert vollständig asynchron als Datenbanktreiber. Derzeit gibt es nur Implementierungen für Postgres und MS SQL Server, die aber wahrscheinlich mit der Zeit wachsen werden. Ich habe mich gefragt, wie es für Jdbi wäre, über R2DBC zu implementieren. Ich verstehe, wenn dies für Sie jetzt keinen Sinn ergibt, aber die Referenz ist hier, falls dies zu einem späteren Zeitpunkt der Fall sein sollte. Kein Stress :)

Interessanterweise stellen sie tatsächlich ihre eigenen Treiber zur Verfügung. Vielleicht gibt es hier also einen Vorteil!

Ich bin neugierig, dies weiter zu untersuchen: Benchmarks, Proof-of-Concept-Code usw. Es scheint einige Einschränkungen zu geben: Ihr r2dbc-Treiber für Postgres wirbt dafür, dass z. B. die Typen BLOB und CLOB dies nicht tun funktioniert noch, und es gibt keine Erwähnung von gespeicherten Prozeduren oder CALL .

Aber zumindest liegt mein persönlicher Fokus im Moment woanders, so dass dies möglicherweise etwas Community-Input und Aufmerksamkeit erfordert, um voranzukommen, da ich im Moment keine Zeit habe, eine Erkundung hier zu eröffnen, und ich kann mir nicht vorstellen, dass andere Kernmitglieder danach suchen springe auch drauf.

Ich freue mich darauf, mehr zu hören, auch wenn nur andere Mitglieder der Community abstimmen, dass dies ein benötigtes Feature ist.

Toll, dieses Ticket zu sehen.

Ich wollte schnell zwei Dinge fallen lassen, um den Status von R2DBC zu klären:

• Es ist noch eine junge Initiative und Dinge wie BLOB/CLOB und Unterstützung von Stored Procedures müssen implementiert werden, bevor wir GA gehen.
• Treiber sind vollständig reaktiv und nicht blockierend, was bedeutet, dass der gesamte E/A-Teil nicht blockierend ist. Es gibt keine Auslagerung von Blockierungsarbeit in Thread-Pools.

Auf jeden Fall zielt R2DBC darauf ab, dass ein SPI von Client-Implementierungen wie Spring Data R2DBC, R2DBC Client (ein winziger Wrapper auf R2DBC SPI, der einige Ideen von jdbi leiht) und anderen in Zukunft aufgenommen wird.

Ich wollte mich nur einklinken und erwähnen, dass mein ursprünglicher Prototyp/Demonstrations-Client-Layer r2dbc-client basierend auf Jdbis APIs und Ethos entworfen wurde. Wenn Sie sich entscheiden, weiter nachzuforschen, wird es Ihnen bekannt vorkommen 😄.

Ich habe gesehen, wie Leute Rx-Sachen aus JDBI herausgestellt haben ( @hgschmie zum Beispiel). Ich bin mir nicht sicher, was "Unterstützung" für R2DBC bedeuten würde.

Reden Sie davon, R2DBC auf JDBI zu implementieren, JDBi R2DBC Connection s verbrauchen zu lassen, JDBI auszutauschen, um sich auf Rx-Schnittstellen zu konzentrieren, oder ... etwas anderes?

Ich denke, es wäre "Unterstützung von R2DBC-Treibern, die von JDBI verwendet werden sollen und die JDBI-Schnittstellen freigeben"?

R2DBC ist ein asynchroner Ersatz für JDBC.

@brianm R2DBC ist kein JDBC auf ThreadPools. R2DBC bedeutet zwei Dinge:

1. R2DBC-Treiber sind Implementierungen, die eine nicht blockierende Transportschicht verwenden, die org.reactivestreams.Publisher Typen für jede E/A-gebundene Operation zurückgibt. Sie verwenden keine JDBC-Treiber darunter, sondern implementieren Drahtprotokolle von Grund auf.
2. R2DBC ist ein standardisierter (herstellerunabhängiger) SPI, der es ermöglicht, darauf Client-Bibliotheken aufzubauen. Treiberimplementierungen können wie heute für JDBC ausgetauscht werden.

Sprechen Sie über die Implementierung von R2DBC auf JDBI, wobei JDBi R2DBC-Verbindungen konsumiert?

Ja, das ist im Grunde gemeint. Ein R2DBC-spezifisches JDBI-Modul, das Project Reactor/RxJava2/Zerodep-Typen zurückgibt.

Ich bin mir ziemlich sicher, dass ich verstehe, was R2DBC ist, und ich denke, es ist eine sehr gute Sache.

Ich versuche herauszufinden, was "JDBI-Unterstützung" dafür ist!

Vielleicht schreiben Sie ein Codebeispiel dessen, was Sie über die API von JDBI erwarten?

Wie wäre es, wenn Sie Folgendes für den Anfang unterstützen:

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

Die schnittstellenbasierte Unterstützung könnte wie folgt aussehen:

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

Ich habe keine Meinung zu RxJava vs. Project Reactor, daher habe ich versucht, Varianten aufzulisten, die beide APIs verwenden.

Könnte jemand erklären, was hier genau vorgeschlagen wird?

Ist R2DBC eine Schicht auf JDBC oder eine eigene Sache? Denn Jdbi ist extrem an JDBC gekoppelt.

R2DBC ist keine Schicht auf JDBC. R2DBC ist eine nicht-blockierende API für den Zugriff auf SQL-Datenbanken und ist eine eigene Sache (R2DBC-Treiber werden normalerweise von Grund auf neu geschrieben und implementieren herstellerspezifische Drahtprotokolle unter Verwendung einer nicht blockierenden E/A-Schicht). Wenn Sie so wollen, ist R2DBC die reaktive Spezifikation für die Integration in SQL-Datenbanken.

Der Vorschlag hier wäre, eine API zu haben, die wie Jdbi aussieht und funktioniert, aber unter R2DBC-Treibern verwendet. Anstatt skalare Objekte zurückzugeben, würde die API Reactive Streams-Typen zurückgeben.

Danke für die Klarstellung. Ich gehe davon aus, dass der erste Schritt hier darin besteht, einen Jdbi-Fork oder -Zweig zu prototypieren, der minimal als PoC dient und zeigt, wie die obigen Beispiele auf R2DBC implementiert werden. Von dort aus müssten wir einen Weg zur Integration parallel zur bestehenden JDBC-Unterstützung finden oder als Hard Fork besser etablieren. Wie Matthew oben erwähnt, sind wir derzeit eng mit JDBC verbunden, und Änderungen daran werden wahrscheinlich sowohl eine Menge harter Arbeit sein als auch möglicherweise bahnbrechende Änderungen erfordern.

Ich freue mich, dies auf dem langfristigen Radar des Projekts zu haben, aber ich erwarte nicht, dass es ohne signifikante Beteiligung der Gemeinschaft schnell vorankommt.

@stevenschlansker Wir haben ursprünglich einen r2dbc-Client erstellt , der von JDBI inspiriert wurde. Was halten Sie von einem Pull-Request/PoC, der ein r2dbc Modul ( jdbi-r2dbc ) als Beitrag des R2DBC-Clients zurück in JDBI einführt, wie folgt:

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

Sehr cool. Ja, wenn sich die Arbeit einigermaßen nahtlos integrieren lässt, inkubieren wir sie gerne in einem Modul!

Es wäre schön, wenn irgendwie die Rdbi API "von" Jdbi -- insofern, wenn Sie eine jdbi.installPlugin(...).registerRowMapper(...) dann werden alle Rdbi Instanzen "kommen" from", dass Jdbi auch ihre Konfiguration erhält. Es wäre auch schön, Dinge wie <strong i="11">@SqlUpdate</strong> CompletableFuture<ResultType> doSomeWork(...); oder was auch immer der geeignete reaktive Typ ist, tun zu können.