Hibernate-reactive: Измените название "Rx"

@emmanuelbernard WDYT?

Да, это всегда было кодовое имя.

Что ж, тогда нам лучше поменять его поскорее, потому что он уже давно превратился в настоящее имя!

Я назначил это себе. Я сделаю это в конце недели, если у кого-то нет возражений.

Я сделаю это в конце недели

Но на что вы собираетесь его менять?

hibernate-reactive звучит неплохо

>

+1 к гибернации-реактивности

В среду, 1 апреля 2020 г., в 7:45 DavideD [email protected] написал:

hibernate-reactive звучит неплохо

>

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

Это нормально, но я не хочу набирать ReactiveSession тысячу раз ....

Мне нравится HibernateRX : быть «реактивным» - это концепция, а не торговая марка RxJava.

Это нормально, но я не хочу набирать ReactiveSession тысячу раз.

Тип? На вашей клавиатуре нет кнопки пробела? :)

Честно говоря, мне не очень нравится использовать префикс в имени класса. Достаточно ли этого в упаковке? Или это слишком запутанно при работе с ORM?
Может быть, мы могли бы использовать R качестве префикса?

Вот краткое изложение вариантов, которые я мог придумать (не стесняйтесь предлагать что-то другое):

1. org.hibernate.rx.RxSession (текущий)
2. org.hibernate.rx.Session
3. org.hibernate.reactive.ReactiveSession
4. org.hibernate.reactive.Session
5. org.hibernate.reactive.RSession
6. org.hibernate.rx.RSession

Есть другие предложения?

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

1. class AbstracRxtEntityPersister extends RxEntityPersister
2. class AbstracReactivetEntityPersister extends ReactiveEntityPersister

Сейчас это не очень согласовано в проекте. Иногда классы используют
RxAbstractEntityPersister

Думаю, я воспользуюсь вариантом 3: org.hibernate.reactive.ReactiveSession
Но я подожду, чтобы услышать, есть ли лучшие предложения или сильные мнения против этого.

Я бы тоже проголосовал за 3 , но, может быть, у @vietj тоже есть мнение?

Да, я пытался придумать лучший вариант, но, честно говоря, у меня ничего не получилось, и я согласен с вами, ребята: нет ничего лучше, чем ReactiveSession .

Я ненавижу отсутствие псевдонимов типов в Java. Единственный прием, который я могу придумать, - это иметь Reactive.Session , Reactive.Query и т.д. в качестве внутренних интерфейсов некоторого типа Reactive , что позволит вам использовать статический импорт, если хотите. Это разумный подход, но я никогда не видел, чтобы кто-то еще использовал его на Java.

Мне нравятся варианты 2 и 4:

• org.hibernate.rx.Session
• org.hibernate.reactive.Session

Пусть имя пакета указывает на то, что классы являются «реактивными». Если нам нужно добавить Rx / Reactive в качестве префикса ко всем классам, тогда классы будут казаться гражданами второго сорта.

Основной недостаток, который я вижу в использовании того же имени класса, что и нереактивные аналоги, будет заключаться в том, что мы ожидаем, что пользователи будут использовать оба класса в одном и том же классе (таким образом, требуя полностью определенных имен классов везде, где выражаются типы), но AFAIK, который не должен случаться?

Мне нравятся варианты 2 и 4:

• org.hibernate.rx.Session
• org.hibernate.reactive.Session

FTR Я тоже с этим согласен, однако хочу отметить, что это увеличивает риск ошибки при автоимпорте.

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

• MutinySession для мятежа
• StagedSession или что-то в этом роде за CompletionStage
• так далее

WDYT?

Является ли это единственным API-интерфейсом, ориентированным на пользователя, который предоставляет варианты реактивного типа?

Является ли это единственным API-интерфейсом, ориентированным на пользователя, который предоставляет варианты реактивного типа?

Среди «основных» API также можно рассмотреть эквиваленты Query .

Для записи, я считаю, что «Rx» звучит хорошо, и он вообще не принадлежит проекту RxJava - как я уже упоминал выше - поэтому я хотел бы сохранить это имя, поскольку другие просто звучат неправильно.

О структуре договора

Мне не нравится перегрузка интерфейса Session , как указал Гэвин, это приводит к ошибкам автоматического завершения и когнитивной перегрузке для людей.

Итак, +1 для любого из следующих паттернов:

• MutinySession , RxJava2Session , JDKReactiveSession (для CompletionStage и Flow)
• SessionMutiny , SessionRxJava2 т. Д.

Альтернативный шаблон - reactiveSession.forMutiny().[...] , reactiveSession.forJDK().[...] но он, скорее всего, превратил бы в адский кошмар зависимости. reactiveSession.unwrap(MutinySession.class) , похоже, не приносит пользы.

Некоторые дополнительные моменты:

• Rx имеет 3 несовместимые версии, поэтому необходимо указать номер версии в контракте.
• CompletionStage брат по руке - Flow, поэтому я назвал его JDKReactiveSession
• RxJava имеет несколько множественных и несколько одиночных типов, поэтому каждый метод RxJavaXSession , скорее всего, будет «перегружен», например, fetchAsSingle() т. Д.

Я полагаю, что у Query также будет реактивный аналог. Кстати, мне пришло в голову, что параметры запроса должны принимать как прямой тип, так и реактивные оболочки, например Uni<String>

По названию, я думаю, Hibernate ORM Reactive в порядке hibernate-orm-reactive но @FroMage что насчет "Panache Rx", проходит ли оно аналогичное преобразование?

@emmanuelbernard, обратите внимание, что текущий способ получить Session и SessionFactory :

RxSessionFactory sessionFactory = emf.unwrap(RxSessionFactory.class);
RxSession session = sessionFactory.openRxSession();

Я вполне доволен этим шаблоном.

JDKReactiveSession

Фу. Это выглядит ужасно для того, что мы, вероятно, так часто увидим в коде.

Я полагаю, что Query также будет иметь реактивный аналог.

Да, он уже есть и в настоящее время называется RxQuery . Но пока он ничего не делает.

Честно говоря, мне все больше нравится такой вариант:

//I want to try out Mutiny
Mutiny.SessionFactory sessionFactory = emf.unwrap(Mutiny.SessionFactory.class);
Mutiny.Session session = sessionFactory.openReactiveSession();
Mutiny.Query = session.createQuery(hql);

или:

//I want to try it out with CompletionStage
Stage.SessionFactory sessionFactory = emf.unwrap(Stage.SessionFactory.class);
Stage.Session session = sessionFactory.openReactiveSession();
Stage.Query = session.createQuery(hql);

А затем, когда я точно знаю, что использую Mutiny , я могу просто написать:

import static org.hibernate.reactive.mutiny.Mutiny.*;

...

SessionFactory sessionFactory = emf.unwrap(SessionFactory.class);
Session session = sessionFactory.openReactiveSession();
Query = session.createQuery(hql);

Я думаю, что внешний класс существенно облегчает проблему автоматического импорта. (Хотя у него есть и другие недостатки.)

это выглядит великолепно @gavinking

@gavinking Мне очень нравится твое последнее предложение.

Я думаю, что внешний класс существенно облегчает проблему автоматического импорта. (Хотя у него есть и другие недостатки.)

Например?

@DavideD хорошо, что одним из недостатков является то, что IDE обычно не добавляют статический импорт автоматически. (Хотя вы можете настроить их для этого.)

@emmanuelbernard, обратите внимание, что текущий способ получить Session и SessionFactory :

RxSessionFactory sessionFactory = emf.unwrap(RxSessionFactory.class);
RxSession session = sessionFactory.openRxSession();

Я вполне доволен этим шаблоном.

JDKReactiveSession

Фу. Это выглядит ужасно для того, что мы, вероятно, так часто увидим в коде.

Судя по большинству отзывов, которые я собрал, люди ненавидят CompletionStage и выбирают RxJava или друзей. Так что эта версия была бы выбором бедняка.

Судя по большинству отзывов, которые я собрал, люди ненавидят CompletionStage и выбирают RxJava или друзей. Так что эта версия была бы выбором бедняка.

Вы пытаетесь убедиться, что он не может быть использован? :-D

Судя по большинству отзывов, которые я собрал, люди ненавидят CompletionStage и выбирают RxJava или друзей. Так что эта версия была бы выбором бедняка.

Конечно, я тоже это ненавижу.

IDE обычно не добавляют статический импорт автоматически

Это довольно сильный аргумент против этого, что вы не можете написать Session и получить предложение IDE по импорту static Mutiny.Session , поэтому вам всегда нужно вводить его с префиксом Mutiny.Session . И все документы также должны включать импорт, что затрудняет копирование / вставку.

Судя по названию, я думаю, что Hibernate ORM Reactive отлично подходит для hibernate-orm-reactive, но

да. Это всегда было кодовое имя.

Это довольно сильный аргумент против того, что вы не можете написать Session и получить предложение IDE для импорта

Я не думаю, что это так сильно: они все еще могут писать Mutiny.SessionFactory , как мы, вероятно, должны придерживаться в документации (так что нам не придется включать импорт, хотя, возможно, мы всегда должны, как правило) .

@FroMage не так уж и плохо. В intelliJ перейдите в « Настройки»> «Стиль кода»> «Java»> «Импорт» . В Eclipse есть нечто подобное.

Как бы то ни было, на мой взгляд, Mutiny следует рассматривать как API по умолчанию. Остальное может попасть под какой-нибудь пакет compat . Даже версия CompletionStage/Flow :-)

Обновление: учитывая документы Mutiny, есть ли смысл запекать в совместимости? Просто положитесь в этом на Mutiny и возложите (довольно небольшую) ношу на разработчика, чтобы выполнить преобразование, если им нужно преобразовать один в другой.

• https://smallrye.io/smallrye-mutiny/#_how_do_i_interact_with_completionstages
• https://smallrye.io/smallrye-mutiny/#_how_do_i_interact_with_rx_java_2
• https://smallrye.io/smallrye-mutiny/#_how_do_i_interact_with_reactor

Клемент добавляет батуты в Mutiny, что может быть еще одним аргументом в пользу того, чтобы сделать Mutiny по умолчанию для Reactive Hibernate.

Это обсуждение развернулось в списке рассылки hibernate-dev. Мы все, кажется, склонны использовать Hibernate Reactive ... хорошо?

Было бы лучше ответить в списке рассылки.

Напоминание, для регистрации см .:

• https://lists.jboss.org/mailman/listinfo/hibernate-dev

В частности, это большая тема, касающаяся этой проблемы (среди прочего):

• https://lists.jboss.org/pipermail/hibernate-dev/2020-May/018774.html

Реактивный режим гибернации, хорошо?

:шампанское:

В частности, это большая тема, касающаяся этой проблемы (среди прочего):

Какая большая ветка, там одно электронное письмо;)

Лично мне все еще больше нравится HibernateRX - я согласен с Санне, что RxJava не владеет «Rx», а IMO HibernateRX - запоминающееся имя. Hibernate Reactive больше похож на описание, чем на имя. Только мои 0,02 доллара, и я не хотел загромождать этим цепочку рассылки.

Лично мне все еще больше нравится HibernateRX - я согласен с Санне, что RxJava не владеет «Rx», а IMO HibernateRX - запоминающееся имя. Hibernate Reactive больше похож на описание, чем на имя. Только мои 0,02 доллара, и я не хотел загромождать этим цепочку рассылки.

Проблема @aguibert в том, что означает x в вашем имени Hibernate Rx?
Реактивное расширение - это что-то конкретное https://en.m.wikipedia.org/wiki/Reactive_extensions

правильно, я бы подумал, что Hibernate Rx будет просто обозначать «Hibernate Reactive Extensions». Реактивные расширения - это что-то конкретное, но оно относится к концепции, а не к конкретному продукту или проекту. ИМО, то, что мы здесь делаем, все еще соответствует этой концепции.

Поскольку похоже, что мы настолько близки к консенсусу, насколько мы когда-либо сможем достичь с названием «Hibernate Reactive», я полностью согласен с этим названием.

Я закрою это, так как из-за письма Эммануэля в списке рассылки не было никакого возмущения :)

Hibernate Reactive это так! Еще раз спасибо

Далее следует # 111