Jdbi: Поддержка R2DBC

Привет, Вон, спасибо за указатель. Reactive - это очень ново и интересно, но я понимаю, что текущая реализация JDBC и, по сути, само программное обеспечение сервера базы данных делает его плохим кандидатом для реактивных концепций на нижних уровнях. На сервере базы данных есть рабочие процессы, которые принимают запросы и выдают результаты, и каждый процесс будет работать над своим запросом до завершения. Нет возможности асинхронно отправлять 10 запросов и ждать их результатов.

Это означает, что по мере реализации реактивного JDBC вы в конечном итоге обнаружите, что должны реализовать пул потоков старого стиля, который содержит ваши соединения / дескрипторы, сервисные запросы, а затем передает результаты в реактивную структуру. Это означает, что у вас могут быть некоторые преимущества реактивного кода, в частности, вы можете писать реактивный код, но это серьезно ограничивает преимущества масштабируемости, которые пытается достичь реактивный.

Поэтому мы определенно приветствуем интеграцию API, но если состояние мира JDBC не изменилось с тех пор, как я в последний раз исследовал, это будет несколько ограниченная оболочка, которая просто скрывает тот факт, что код под ней по-прежнему является многопоточным кодом старой школы.

Я ценю предложение ускорить работу на вашей платформе, но наша библиотека гордится тем, что она почти полностью автономна и не является частью какой-либо платформы или фреймворка. Так что, хотя мы можем искать вдохновения и всегда готовы сотрудничать для достижения общих целей, мы абсолютно независимый проект :)

Привет, Стивен! Спасибо за ваши комментарии. В настоящее время мы решаем проблему реактивного над-JDBC, сериализуя запросы внутри акторов в наших реализациях vlingo-symbio . Вы можете создать столько JDBCObjectStoreActor сколько имеет смысл для ваших ограничений соединения, но сами акторы обращаются к JDBC синхронно. Более того, клиент реализаций ObjectStore запущенных на акторах, не блокируется во время выполнения запросов.

У меня нет полного понимания R2DBC, но он позиционируется как полная замена JDBC и работает полностью асинхронно как драйвер базы данных. В настоящее время существуют реализации только для Postgres и MS SQL Server, но, вероятно, со временем они будут расширяться. Мне было интересно, каково было бы реализовать Jdbi поверх R2DBC. Я понимаю, если это не имеет для вас смысла сейчас, но ссылка здесь на случай, если это произойдет в будущем. Нет стресса :)

Интересно, что они действительно предоставляют свои собственные драйверы. Так что, может быть, здесь есть какая-то польза!

Мне любопытно изучить это дальше: тесты, проверка концептуального кода и т. Д. Кажется, есть некоторые ограничения: их драйвер r2dbc для postgres рекламирует, что, например, типы BLOB и CLOB не еще не работают, и вообще нет упоминания о хранимых процедурах или CALL .

Но, по крайней мере, мое личное внимание прямо сейчас находится в другом месте, поэтому для продвижения вперед может потребоваться некоторый вклад сообщества и внимание, так как у меня сейчас нет времени, чтобы начать исследование здесь, и я не думаю, что другие основные участники стремятся прыгать тоже.

Будем рады услышать больше, даже если другие члены сообщества проголосуют за то, что это необходимая функция.

Приятно видеть этот билет.

Я хотел бы быстро отбросить две вещи, чтобы прояснить состояние R2DBC:

• Это все еще молодая инициатива, и такие вещи, как поддержка BLOB / CLOB и хранимых процедур, должны быть реализованы до того, как мы перейдем к GA.
• Драйверы являются полностью реактивными и неблокирующими, что означает, что вся часть ввода / вывода не блокируется. Нет разгрузки блокирующей работы в пулы потоков.

В любом случае R2DBC стремится к тому, чтобы SPI был подхвачен клиентскими реализациями, такими как Spring Data R2DBC, R2DBC Client (крошечная оболочка поверх R2DBC SPI, которая предоставляет некоторые идеи из jdbi) и многое другое.

Просто хотел вмешаться и упомянуть, что мой первоначальный прототип / демонстрационный клиентский уровень, r2dbc-client был разработан на основе API-интерфейсов и этоса Jdbi. Если вы решите продолжить расследование, я думаю, вам это покажется знакомым 😄.

Я видел, как люди выставляли Rx-материалы из JDBI (например, @hgschmie ). Я не уверен, что будет означать «поддержка» R2DBC.

Вы говорите о реализации R2DBC поверх JDBI, использовании JDBi R2DBC Connection s, замене JDBI на интерфейсы Rx или ... чем-то еще?

Я думаю, это будет «поддерживать драйверы R2DBC, которые будут использоваться JDBI, открывая интерфейсы JDBI»?

R2DBC - это асинхронная замена JDBC.

@brianm R2DBC - это не JDBC в ThreadPools. R2DBC означает две вещи:

1. Драйверы R2DBC - это реализации, использующие неблокирующий транспортный уровень, возвращающий типы org.reactivestreams.Publisher для каждой операции, связанной с вводом-выводом. Они не используют драйверы JDBC, а реализуют проводные протоколы с нуля.
2. R2DBC - это стандартизированный (не зависящий от производителя) SPI, позволяющий создавать клиентские библиотеки поверх. Реализации драйверов можно менять местами, как это делается сегодня для JDBC.

Вы говорите о реализации R2DBC поверх JDBI, когда JDBi использует соединения R2DBC?

Да, это то, что в основном означает. Наличие модуля JDBI для R2DBC, возвращающего типы Project Reactor / RxJava2 / Zerodep.

Я почти уверен, что понимаю, что такое R2DBC, и считаю, что это очень хорошая вещь.

Я пытаюсь понять, что это за "поддержка JDBI"!

Может быть, напишите пример кода того, что вы собираетесь делать через API JDBI?

Как насчет поддержки для начинающих:

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

Поддержка на основе интерфейса может выглядеть так:

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

У меня нет мнения о RxJava и Project Reactor, поэтому я попытался перечислить варианты, используя оба API.

Может кто-нибудь прояснить, что именно здесь предлагается?

R2DBC - это слой поверх JDBC или отдельная вещь? Потому что Jdbi в высшей степени связан с JDBC.

R2DBC не является слоем поверх JDBC. R2DBC - это неблокирующий API для доступа к базам данных SQL, и он сам по себе (драйверы R2DBC обычно пишутся с нуля, реализующие проводные протоколы конкретного поставщика с использованием неблокирующего уровня ввода-вывода). Если хотите, R2DBC - это реактивная спецификация интеграции с базами данных SQL.

Здесь предлагается API, который выглядит и работает как Jdbi, но использует драйверы R2DBC. Вместо возврата скалярных объектов API будет возвращать типы реактивных потоков.

Спасибо за разъяснения. Я ожидаю, что первым шагом здесь будет создание прототипа вилки или ветки Jdbi, которая в минимальной степени служит PoC, показывающим, как реализовать приведенные выше примеры поверх R2DBC. Оттуда нам нужно будет определить путь к интеграции параллельно с существующей поддержкой JDBC или установить, что это было бы лучше в качестве хард-форка. Как указывает Мэтью выше, мы в настоящее время тесно связаны с JDBC, и изменение, которое, вероятно, потребует много тяжелой работы, а также потенциально потребует критических изменений.

Я очень рад, что это будет в центре внимания проекта в долгосрочной перспективе, но я не ожидаю, что он продвинется быстро без значительного участия сообщества.

@stevenschlansker Изначально мы создали r2dbc-client , вдохновленный JDBI. Что вы думаете о запросе на вытягивание / PoC, который вводит модуль r2dbc ( jdbi-r2dbc ) в качестве вклада клиента R2DBC обратно в JDBI в следующих строках:

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

Очень круто. Да, если работа может быть интегрирована достаточно легко, мы с радостью инкубируем ее в модуле!

Было бы неплохо, если бы каким-то образом Rdbi api "происходил из" Jdbi - в том смысле, что когда вы выполняете jdbi.installPlugin(...).registerRowMapper(...) тогда любые Rdbi экземпляры, которые "приходят от "того, что Jdbi тоже получают свою конфигурацию. Также было бы неплохо иметь возможность делать такие вещи, как <strong i="11">@SqlUpdate</strong> CompletableFuture<ResultType> doSomeWork(...); или любой другой подходящий реактивный тип.