***
Вакансии можно постить в основную группу если: 1) указаны зарплатные ожидания и одно из двух 2.1. это или релокация, 2.2.  или это удаленка. Если что то другое, то можно постить вакансии в @jvmtalk
***

спасибо. А это основная считается?

и релокация откуда куда?

да, это основная, jvmtalk - дополнительная.
релокация из РФ т.к. большинство участников отсюда.

А чем поможет BigDecimal ?

тем, что @Min и @Max его поддерживают

Спасибо за подсказку

спасибо. Запостила там :)

Способ с брикпоинтом помог.

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

fun findByAddressAndShop(address: String, shop: Shop): List<ShopAddress>

До вызова этого метода магазин в бд не пишется, после этого - появляется. Я попробовал передавать туда не сам Shop, а его идентификатор:
fu

n findByAddressAndShopUuid(address: String, shopUuid: UUID): List<ShopAddress>
н

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

А вот теперь начались странности - даже когда я не использую магазин в поиске, он всё равно сохраняет в БД транзакцию.
Например, я ищу совпадения по телефону по всей базе через

fun findByPhone(phone: String): List<ShopPhone>

До вызова этого метода в базе магазина нет. После него - магазин сохраняется. Как быть?..

fun findByPhone(phone: String): List<ShopPhone>

Я подозреваю, что все дело в том, что хибернейт (оверкомпликейтед говно) видит в качестве возвращаемоего результата ShopPhone, ShopAddress, в которых есть ссылка на Shop. А у тебя в контексте транзакции (вернее наверное в persistence контексте) update на сущность Shop.

Кажется контр-интуинтивным, но все же. А там есть где-нибудь query/native query?

Как вариант - попробовать выпилить из тех сущностей сам Shop (ради эксперимента)
Ну и show-sql: true поставить, чтобы точно все видеть

Гипотеза звучит разумно. Никакие query я не использую, все доверяю хибернейту.

А show-sql транзакции покажет?

Без Shop попробую, интересно, что получится

Но если это предположение подтвердится, то надо будет искать пути решения проблемы) я себе пока слабо представляю, как. Разве что заменить many to many связь на что то самописное

Транзакции нет. Но он может показать что-нибудь ещё интересное. Те же insertы, когда мы внутри транзакции.
Транзакции где-нибудь на уровне прокси надо смотреть, которую @Transactional создает

А зачем создавать магазин, сохранять его, а затем проверять, нет ли адреса?)
Мне кажется можно сначала проверить, а потом вставить. Или там ещё какая-то логика?

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

Ну и с адресом такая же ситуация

Без поля Shop работает, я убрал его в телефоне и обратную связь из магазина.

Бинго. Ну вот, теперь осталось понять, как отучить хибернейт от этой ереси)