но отчеты и аналитика в целом да, не про хибернейт

хибернейт, кстати, никак не затрагивает планировщик

Он же запросы формирует - а по каждому запросу нужен план выполнения.

для динамика в принципе есть criteria api

думаю не поможет. У меня в динамик SQL собирается все начиная от источников и джоинов и заканчивая rollup и cube

Он же запросы формирует - а по каждому запросу нужен план выполнения.

ну так план составляет сама субд для каждого запроса

при чем тут хибер?

ну так план составляет сама субд для каждого запроса

Качество плана зависит от посылаемого запроса

Запрос формирует хибер

Если он кривой запрос сформирует - будет кривой план

если кривой запрос без хибера написать, будет не лучше

тут уже от вас зависит как вы хибер используете

нормально делаете - нормально будет

crud хибер отлично разруливает почти всегда

аналитика и отчеты уже часто завязаны на нативные функции БД, это офк не про хибер

А криво сделаете, можно сказать что сделали нормально но хибернейт зараза виноват =)

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

нормально делаете - нормально будет

Аминь

crud хибер отлично разруливает почти всегда

Круд да, если его много то есть смысл

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

repo.delete(repo.findOne(id))

а можно написать hql

а spring data jpa не умеет в deleteById ?

умеет

все равно нафиг не нужно! только jdbc, только хранимые процедуры!

к теме хибернейта, уже вроде,как все поняли,что хибернет работает хорошо,когда сущностей мало и маппинг примитивный,а если нужно что-то сложней(что обычно и бывает на практике) - используем старый добрый SQL

в моей практике немного по-другому - хибернейт особенно хорош, когда сущностей очень много, но маппинг примитивный

вообще стоит алименкова посмотреть про грабли хибернейта

+

да нормальный хибернейт,просто есть нюансы)

все равно нафиг не нужно! только jdbc, только хранимые процедуры!

++

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

я могу ошибаться,но вроде хибернейт не про индексы

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

не понял

есть у хибернейта режим работы - при старте валидировать схему в БД, что она соответствует сущностям - мне нравится и я активно пользуюсь есть режим - создавать схему в БД при старте - мне не нравится и я не пользуюсь, а пользуюсь системами миграций типа flyway & luquibase есть в JPA аннотация Index с указанием имени и колонок индекса на сущности - она используется во втором случае, но почему-то у меня не используется в первом если никто прямо с этим не сталкивался, то и хрен с ним, разберусь))

есть у хибернейта режим работы - при старте валидировать схему в БД, что она соответствует сущностям - мне нравится и я активно пользуюсь есть режим - создавать схему в БД при старте - мне не нравится и я не пользуюсь, а пользуюсь системами миграций типа flyway & luquibase есть в JPA аннотация Index с указанием имени и колонок индекса на сущности - она используется во втором случае, но почему-то у меня не используется в первом если никто прямо с этим не сталкивался, то и хрен с ним, разберусь))

а должно же по идеии работать

hbm2ddl.auto = update

hbm2ddl.auto = update - так это про обновление схемы

а я хочу при validate чтобы он индексы учитывал и падал, если нету

удали индекс из базы и проверь, заодно нам расскажешь :)

на пропавшие констрейны ругается вроде

https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/tool/schema/internal/AbstractSchemaValidator.java - долез я до исходников

на пропавшие констрейны ругается вроде

про констрейнты там тоже не особо вижу...

хм, потому и написал "вроде", давно дело было

крч мне теперь кажется что майнкрафт не так уж и плохо написан после ынтерпрайза ой-хо-хо

https://dev.by/lenta/main/Voxxed-Days-Minsk

никакого голимого classpath

Ахаха, который остался и те же модули может поломать, но это не точно

нееееееееееееет

никакого голимого classpath

А чем classpath плох, например?

А чем classpath плох, например?

Возможность получить несколько версий одного и того же класса с непредсказуемым выбором между ними?

Возможность получить несколько версий одного и того же класса с непредсказуемым выбором между ними?

это больше к касслоудерам

это больше к касслоудерам

В смысле? Я просто кидаю в classpath две либы, в которых есть один и тот же класс (бывает, их перемещают) и привет

В смысле? Я просто кидаю в classpath две либы, в которых есть один и тот же класс (бывает, их перемещают) и привет

в том смылсел у тебя один и тот же класс, такое может быть если один класслоудер загрузил один, а воторой- второй

соярн за товтологию

OSGI

вроде

та штуку это абузит

Возможность получить несколько версий одного и того же класса с непредсказуемым выбором между ними?

В OSGях выбор предсказуем, но проще от этого не становится

это больше к касслоудерам

Не не. Это к класспасс таки, но несколько версий класса не будет. В рантайме то будет одна, просто неизвестно, какая

Не не. Это к класспасс таки, но несколько версий класса не будет. В рантайме то будет одна, просто неизвестно, какая

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

В смысле? Я просто кидаю в classpath две либы, в которых есть один и тот же класс (бывает, их перемещают) и привет

сорян не понял

тут да, результат не предсказуем, хотелось бы какого-то алгоритма

что бы предусмотреть

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

Во всяких мутных схемах с класслодерами, типа того же OSGi или EE, таки можно иметь два класса с одним именем и пакетом.

тут да, результат не предсказуем, хотелось бы какого-то алгоритма

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

ERROR: S client not available

Во всяких мутных схемах с класслодерами, типа того же OSGi или EE, таки можно иметь два класса с одним именем и пакетом.

ну я про то и подумал, и писал то это все с класслоудерами связанно

тут да, результат не предсказуем, хотелось бы какого-то алгоритма

И что особенно забавно, в OSGi то как раз все предельно предсказуемо)

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

Оу, а я пару раз юзал такую вишку

И что особенно забавно, в OSGi то как раз все предельно предсказуемо)

ну с этой стороны да, а вот когда в райтайме 2-а калсса, и какой вызвется

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

можно воспользоваться слоями и получить аналог OSGi :)

можно воспользоваться слоями и получить аналог OSGi :)

Но зачем?)

И что особенно забавно, в OSGi то как раз все предельно предсказуемо)

да нифига. любая динамика приводит к непредсказуемости

да нифига. любая динамика приводит к непредсказуемости

А нинада динамики) Дали нам вайринг между модулями и харош)

да нифига. любая динамика приводит к непредсказуемости

разве обычная загрузка классов при старте проги - это динамика?

Но зачем?)

вот тебе очень простой пример: две версии того же hibernate-а в одном приложении. Просто потому что приложение большое, и одну часть написали одни люди, а вторую другие. В разное время, и будет легко 2 версии разных библиотек. Сегодня такое можно изолировать загрузщиками, а в 9ке можно лейерами со всеми прелястями которые даёт статический резолв

разве обычная загрузка классов при старте проги - это динамика?

да

во время загрузки класса с ним много чего может произойти :)

вот тебе очень простой пример: две версии того же hibernate-а в одном приложении. Просто потому что приложение большое, и одну часть написали одни люди, а вторую другие. В разное время, и будет легко 2 версии разных библиотек. Сегодня такое можно изолировать загрузщиками, а в 9ке можно лейерами со всеми прелястями которые даёт статический резолв

а ну тут да)

freemarker он еще живой или есть что-то получше? нужно сгенерить класс с константами, скормив часть application.properties

вот тебе очень простой пример: две версии того же hibernate-а в одном приложении. Просто потому что приложение большое, и одну часть написали одни люди, а вторую другие. В разное время, и будет легко 2 версии разных библиотек. Сегодня такое можно изолировать загрузщиками, а в 9ке можно лейерами со всеми прелястями которые даёт статический резолв

Интересный сценарий и вполне реальный, но как мне кажется, такой микс рано или поздно закончится плохо. Надо бы почитать про слои.

Интересный сценарий и вполне реальный, но как мне кажется, такой микс рано или поздно закончится плохо. Надо бы почитать про слои.

такой микс - это суровая правда во многих монолитах сегодня

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

а ещё, слои могут позволить приверженцам OSGi получить теже фишки от рантайма что они сейчас имеют от OSGi-ных реализаций, но поверх JPMS

А нинада динамики) Дали нам вайринг между модулями и харош)

Или о какой динамике речь?

Или о какой динамике речь?

late binding

динамическая загрузка - это и есть динамика

Нинада. Есть импорты/экспорты папкетов/капабилитей через манифест - и харош.

Нинада. Есть импорты/экспорты папкетов/капабилитей через манифест - и харош.

так в манифест ты и прописуешь класспач, а импорты не говорят где реалный путь

где этой проблемы нет или почти нет, так это языки которые компилится в процессорный код

Я имею ввиду - нинада неочевидностей. OSGi многое на разных уровнях позволяет накрутить, в том числе и вклиниться в вайринг и класслодинг. Но... нидада...

есть ли какой-то профит от реактивного спринга сейчас в виду отсутствия асинхронного jdbc?

в нем есть специальный тред пул под блокирующие IO

другой вопрос как сама бд работает

есть ли какой-то профит от реактивного спринга сейчас в виду отсутствия асинхронного jdbc?

выносишь даошки в отдельный пул и радуешься жизни

выносишь даошки в отдельный пул и радуешься жизни

есть какая-нибудь статья?

Spring reactor доки