Hibernate-reactive: экспорт схемы через драйвер Vert.x вместо JDBC

Это немного странно. В то же время я бы предпочел не иметь слишком много способов настройки одной и той же строки подключения. В будущем пользователь, вероятно, сможет использовать ORM с Rx, и он может захотеть использовать Rx API только в некоторых случаях. Также приятно, что мы используем свойства, которые уже знакомы пользователю ORM.

Ах, прости. Я только что понял, что вы не говорили об именах свойств.

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

В любом случае, я думаю, нам нужно будет иметь свойства, аналогичные ORM, но
с удалением части jdbc из имени.
И решите, что произойдет, если задан только один тип свойств.

Пт, 1 мая 2020 г., в 17:53 Эндрю Гвиберт [email protected]
написал:

К тому же я не думаю, что мы должны переусердствовать с созданием вещей.
удобно / знакомо. Например, прямо сейчас мы поддерживаем настройку RX с помощью
URL-адрес протокола jdbc, который удобен / знаком, но не технически
правильно, поскольку мы не используем JDBC.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/hibernate/hibernate-rx/issues/104#issuecomment-622468348 ,
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AAEIQ5JHS5PQ7M7APGO2YVLRPL5APANCNFSM4MXDM4CA
.

В любом случае, я думаю, нам придется иметь свойства, аналогичные свойствам ORM, но с удалением части jdbc из имени.

Я думаю, нам следует придерживаться стандартного формата URL-адресов JDBC, потому что:

• это стандарт
• это хорошо задокументировано поставщиками баз данных
• все это уже знают
• это упрощает одновременную настройку Hibernate RX и обычного Hibernate или обычного JDBC

@DavideD Возможно, я неправильно описал проблему в OP, но как параметры конфигурации вступают в игру для генерации схемы?

Чтобы еще раз заявить о намерении, которое у меня было с этой проблемой, я предлагаю, чтобы процедуры автоматического удаления / создания таблицы могли выполняться без необходимости задействовать какие-либо драйверы JDBC или конфигурацию только для jdbc (если RX повторно использует те же свойства , это нормально)

Ах, прости. Я только что понял, что вы не говорили об именах свойств.

Да, понял. Виноват. Я прочитал это слишком быстро в первый раз.

Кажется немного неудобным требовать от пользователей добавления / настройки драйвера JDBC, если их приложение использует только RX.

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

Итак, ранее я утверждал, что экспорт схемы через JDBC - это нормально. (Что такое реактивный экспорт схемы?)

Однако в телефонном разговоре с @emmanuelbernard и @Sanne я обратил внимание на то, что это действительно потенциальная проблема для пользователей Quarkus.

Мне следовало обратить больше внимания на @aguibert, когда он пытался меня об этом предупредить.

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

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

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

@Sanne

Здесь есть абстракция, которая называется GenerationTarget . Возможно, мы сможем реализовать это, хотя я не уверен на 100%, как именно его подключить.

В противном случае мы могли бы сделать одну вещь - попросить инструмент экспорта схемы экспортировать SCRIPT , а затем просто послать команды одну за другой в БД.

Возможно, мы сможем реализовать это, хотя я не уверен на 100%, как именно его подключить.

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

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

Для справки, помните, что выполнение релиза действительно не займет у нас много времени: около 20 минут. Но тогда нам нужно дождаться центральной синхронизации Maven и всего остального, прежде чем ее можно будет использовать :(
Это означает, что нам нужно выпустить примерно за 24 часа до того, как станет возможен реактивный выпуск.

Я выделю время, чтобы попытаться это сделать. Возможно, это супер-просто. Мы узнаем.

Возможно, это супер-просто. Мы узнаем.

Так что, действительно, это было относительно просто, но возникла проблема, которую я не рассматривал: Hibernate Reactive больше не имеет доступа к метаданным JDBC, что имеет некоторые последствия, но я не думаю, что они слишком ужасны. К счастью, Hibernate был написан, когда метаданные JDBC были очень ненадежными и на самом деле не зависели от них.

Я думаю, это нормально.

Также он обнаружил ошибку в ForeignKeys где Hibernate Reactive фактически использовал бы соединение JDBC для получения снимков из базы данных! Я открою отдельный отчет об этой проблеме.

Отлично, спасибо!

Исправление Гэвина было объединено в ORM; создание схемы должно быть теперь выполнимо.

Я подозреваю, что автоматическое обновление схемы немного сложнее - можем ли мы согласиться, что это менее важно для первой версии?

Исправление Гэвина было объединено в ORM; создание схемы должно быть теперь выполнимо.

Спасибо.

Я подозреваю, что автоматическое обновление схемы немного сложнее.

О, намного сложнее, поскольку текущая реализация полностью основана на метаданных JDBC, IIRC.

Можем ли мы согласиться, что это менее важно для первого разреза?

Да, я вообще не собираюсь работать над этим на данном этапе. Я тоже не думаю, что это нужно.

@Sanne, как скоро мы получим выпуск ядра ORM с этим изменением?

@gavinking, мы можем запланировать релиз на понедельник. Я задаюсь вопросом - если, возможно, потребуются дополнительные изменения, может быть, лучше отложить?
Мы также работаем над некоторыми другими исправлениями, которые необходимы Quarkus - поэтому, хотя мы можем выпустить одно, когда захотим, чем позже, тем больше исправлений.

@Sanne Не держись, этот комментарий был сделан до того, как я обнаружил серьезность # 113.

@gavinking в какой-то момент не могли бы вы написать о проблеме с Vertx-sql-client, описав, какие типы метаданных БД необходимы для Hibernate? Клиент Vertx должен иметь лучший API метаданных, чем когда-либо.

+1 для Андрея!

У нас есть инициатива по созданию API получения метаданных для Postgres в
https://github.com/eclipse-vertx/vertx-sql-client/pull/513. Отзывы будут
безусловно, поможет нам создать лучший универсальный API для этого.

В четверг, 14 мая 2020 г., в 21:58 Эндрю Гвиберт [email protected]
написал:

@gavinking https://github.com/gavinking в какой-то момент не могли бы вы написать
проблема с Vertx-sql-client, описывающая, какие типы метаданных БД
нужен Hibernate? У клиента Vertx должен быть лучший API метаданных
чем в настоящее время когда-нибудь.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/hibernate/hibernate-reactive/issues/104#issuecomment-628654875 ,
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/ABJV4JODSAYQT7BG2TWHZI3RRP2JFANCNFSM4MXDM4CA
.

Инструменты управления схемой нуждаются в доступе к информации в information_schema.tables и, я думаю, также в information_schema.key_column_usage .

Инструменты управления схемой нуждаются в доступе к информации в information_schema.tables и, я думаю, также в information_schema.key_column_usage .

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

Готово!

И это делается довольно прозрачным для пользователя способом: если у них настроен драйвер JDBC или пул соединений, то Hibernate ORM будет выполнять экспорт схемы через JDBC, но если у них нет драйвера JDBC, то экспорт схемы выполняется поверх драйвер Vert.x сработает.

Это потрясающе!
Большое спасибо

И это делается довольно прозрачным для пользователя способом: если у них настроен драйвер JDBC или пул соединений, тогда Hibernate ORM выполнит экспорт схемы через JDBC, но _iff_ у них нет драйвера JDBC, а затем экспорт схемы будет осуществляться через драйвер Vert.x сработает.

просто любопытно, почему он должен сначала попытаться использовать подход JDBC? Если у нас есть возможность запускать его поверх vertx, почему бы не делать это всегда?

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

просто любопытно, почему он должен сначала попытаться использовать подход JDBC? Если у нас есть возможность запускать его поверх vertx, почему бы не делать это всегда?

Что ж, если у вас есть обычный Hibernate, настроенный с обычным драйвером JDBC, почему бы не использовать его? Реактивный экспорт схемы не имеет смысла. Чтобы это сработало, мы должны сделать в конце совершенно неприятный join() , который Vert.x очень расстраивает.

как узнать, действительно ли это другое соединение указывает на ту же БД?

Потому что это тот же URL-адрес JDBC?