короче надо больше деталей. секунду, опишу уже ровным подчерком

http://stackoverflow.com/questions/18423019/how-to-enable-load-time-runtime-weaving-with-hibernate-jpa-and-spring-framewor

Вообще тут все просто - создаешь свою SessionFactory в runtime и все

А бизнес-кейс какой?

Вообще тут все просто - создаешь свою SessionFactory в runtime и все

новые классы должны энхэнс пройти в рантайме

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

я имею ввиду как с моделями

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

у вас юзеры в качестве описания отчетов используют джаву?)

т.е. вот БА взял и написал на джаве класс и скомпилировал

норм так

Ну да, не проще ли на предикатах подготовить конструктор отчетов?

это не конечные юзеры и речь не совсем об отчетах, так проще объяснять. NDA и прочая чушь

окей. Роман, в любом случае. моё скромное мнение - вы решаете проблему не с того угла, поэтому так сложно

у хибера есть энхэнс плагин

с помощью него вся магия и происходит

вейт э сек, на сколько я тут читаю эта штука нужна для дэзи лоада, а у меня немного другой кейс

ну тебе в рантайме обычные классы надо превратить в хиберовские

это то, что я понял

классы аннотированы как надо, все сделано

Опять понаехали

Я читатль. Морозить глупые вопросы еще готов, а так добавил и буду переодически почитывать, что в этом плохого? ДА и правила тут суровые =)

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

на Jdbc

мы уже сделали, но мне не нравится

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

то есть часть проекта вся такая хибернейт

а другая часть суровый jdbctemplate

все, что я по этому поводу думаю wut?

не уж то нельзя натровить хибернейт на сущности, а он уж там как нибудь сам?

оказалось, это как то непонятно и сложно

для лазалки в БД он какой то слишком умный(

я не понимаю причин не любить jdbc

в сто раз проще и понятнее чем Hibernate

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

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

хиернейт вообще для меня впервые за 7мь лет службы

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

для этого есть connection pool

который сам разрулит

но это не точно что разрулит

но это не точно что разрулит

почему?

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

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

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

это надо тестировать

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

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

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

я скажу так, если у вас много дублирования кода, то конечно думайте как бы все обобщить, перевести на Hibernate или на Jdbc, но в целом Hibernate и JPA склонны крайне усложнять код в сложны системах, где много связей между таблицами, где много JOIN в запросах, и вот тут с Hibernate начинается боль

ну вообщем так все и случилось)

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

да не, мы ее jdbc забороли, просто мне интересно, можно ли было поступить иначе)

т.е. вы её решили уже?

А просто HQL/SQL запросы никак?

можно. использовать другой подход для формирвоания отчетов

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

А какие другие решения?

ну jdbc ~= sql

JDBCTemplate == spring

В смысле какой контраст с какими еще другими решениями? Что за проект хоть?

В смысле какой контраст с какими еще другими решениями? Что за проект хоть?

контраст jdbc с хибернейтом

А hibernate как вы используете? Criteria API, HibernateTemplate, JPA NamedQUery, Spring Data JPA?

Criteria API +, JPA NamedQuery +, остально фиг знает)

Ну вот HQL, Spring Expression и Groovy скрипты

Всем привет. Сейчас смотрю на один код. Суть такая: есть список определённых эелементов и для него делается stream().forEach(...) а имеет ли вообще это смысл, если можно в данном конкретном случае сделать for(MyClass: cls: list() { ...}?

Всем привет. Сейчас смотрю на один код. Суть такая: есть список определённых эелементов и для него делается stream().forEach(...) а имеет ли вообще это смысл, если можно в данном конкретном случае сделать for(MyClass: cls: list() { ...}?

ну типа модно

если между stream().forEach() - вообще ничего нет

за такое руки обрывать надо

ERROR: S client not available

разницы нет

Всем привет. Сейчас смотрю на один код. Суть такая: есть список определённых эелементов и для него делается stream().forEach(...) а имеет ли вообще это смысл, если можно в данном конкретном случае сделать for(MyClass: cls: list() { ...}?

более того, можно сразу list.forEach(..)

Удобно, если в форич передается референс на метод

руки то обрывать необязательно

и он развернется в обычный форич

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

Нельзя вызывать стрим только ради форича

Нельзя вызывать стрим только ради форича

почему?

можно конечно

почему?

100% он не объяснит

но не красиво

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

чем простой вызов лупа

ну forEach если у всех и без стрима

forEach() у коллекции и у стрима — разные внутри, у коллекции там просто луп

а у стрима?

а у стрима миллион проверок с кучей абстракций

ну ты перегибаешь

да хотя бы то что мы создаём объект

а он нам и не нужен

там всего лишь форич у сплитератора вызывается

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

Экономия на спичках

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

просто чуть более затратно

но экономия на спичках

с проверкой parallel \ not parallel

Экономия на спичках

но это ведь не какая то сложная оптимизация

ну понятное дело что в продакшене никто разницы не увидит между стримовским форичем и обычным

тип почему не следовать этому правилу

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

идея предлагает убрать из такой конструкции stream()

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

так юзай форыч