Я понимаю как работает меппинг в Hibernate, только в данном случае мне нужно за один запрос вытащить всех юзеров с их профилями(сразу) а не делать дополнительно кучу LAZY запросов.
> Не совсем понял. Не хватает подстановки запросов?
Не хватает динамики в запросах.
В одном случае мне нужен такой запрос:
Query(«SELECT u FROM User u JOIN FETCH u.profile»)
В другом случае:
Query(«SELECT u FROM User u»)
А в третьем:
Query(«SELECT u FROM User u JOIN FETCH u.profile JOIN FETCH u.role»)
А к этому мне иногда еще нужна постраничная разбивка с сортировкой, иногда просто сортировка.
У меня тут два варианта решения проблемы:
1. Написать три разных метода и сверху каждого сделать аннотации Query.
2. Сделать один метод в котором динамически строить запрос на основе входных параметров(нужно ли вытаскивать профиль или нет, нужна ли роль или нет).
Второй вариант для меня предпочтительней потому что в рантайме я могу изменить запросы. Поэтому что бы так сделать мне приходится отдельно писать метод и в нем с помощью QueryDSL описывать логику выборки данных.
> Предложите другой вариант, который хорошо интегрируется с Spring MVC быстрый и у которого удобный синтаксис. JSTL не предлагать :)
Варианты есть: jtwig.org, www.mitchellbosecke.com/pebble/home, github.com/greenlaw110/Rythm, github.com/jreijn/spring-comparing-template-engines.
Мы используем Pebble engine.
> Я посмотрел QueryDSL выглядит не очень. Опять же делать свой репозиторий это возврат к временам до Spring Data. И да с чего у вас каша будет? Вот определен у вас интерфейсы ваших репозиториев, ну размещайте туда все вызовы через аннотации. Ну все же можно. В итоге кода получается меньше и каши меньше.
Это возможно дело вкуса. Я попробую описать причины по которым сейчас я не вижу смысла в Spring Data JPA.
1. Короткие методы — не нужны, да первые ощущения от findAll положительные, но со временем понимаешь что тут у тебя метод findAll а вот тут Query, а там еще Specifications. А нужно чтобы все выглядело одинаково(или хочется).
2. Query не гибкий метод потому что иногда нужны динамические запросы. По итогу используем Criteria API, потому что Specifications нам явно не хватает.
В результате я смотрю на Spring Data JPA и думаю, а зачем мне весь этот сахар если он покрывается стандартным JPA полностью, а плюсов никаких не дает. Только каша из разных способов сделать одно и то же.
С другой стороны JPA мне тоже не хватает, потому что у него не все хорошо с нативными запросами, с джоинами по несвязанным таблицам и выборкой отдельных полей. В результате мы стали использовать QueryDSL который позволяет делать типобезопасные, универсальные запросы к JDBC,JPA и collections.
Я напишу несколько замечаний/дополнений которые могут быть полезны юзерам:
1. Вместо *.properties можно использовать *.yml — меньше текста, проще читать.
2. Я бы не советовал использовать Thymeleaf, он довольно медленный и у него КРАЙНЕ неудобный синтаксис для шаблонизатора.
3. Приложение можно запустить не только с помощью плагина Gradle но и из класса Application.
4. Gradle для нас оказался сыроват, мы используем менее гибкий но более стабильный Maven.
5. Spring boot умеет обновлять вашу схему в БД с помощью Hibernate. Свойство в application.properties, spring.jpa.hibernate.ddl-auto.
6. Я бы не советовал использовать Spring Data JPA. Ваш код 100% может обойтись без этого модуля, лучше возьмите QueryDSL и напишите всю прослойку Repository самостоятельно. Иначе в определенный момент вы получите кашу из методов-запросов, запросов Query, нативных запросов в SQL или с помощью JPA Criteria API. Если вы все таки решили использовать Spring Data JPA, то не поленитесь посмотреть исходники там есть интересные штуки типо AbstractPersistable.
На 1200 уже хреново работать, мы в офисе замеряли CO2 и уже после 1100 проявляются признаки сонливости, потери внимания, у людей начинает болеть голова, а вот при 800 все отлично.
Кстати по теме статьи, многое что вы описали я испытываю на собственной шкуре, в плане удобства рабочего места. Тут тебе и невозможность открыть окно(кондиционеры же) и дискомфорт от работы с некоторыми коллегами(например некоторые громко говорят, а некоторые любят яркий свет и т.д.). И невозможность установить софт который хочу я, например Linux. И высокие уровень CO2 и невозможность компании хоть что то с этим сделать, ведь офис снимается.
Я тоже пытался понять как зайти в личный кабинет имея на руках их симку, но так и не понял :((. Возможно это все потому что купил я ее на пол года раньше, но блин я надеялся что будет работать.
Не по теме, но мы еще используем MapStruct для возврата плоских объектов JPA. А зависимости фетчим в запросе. Получается не очень гибко, но это одна большая проблема — возвращать(Rest) сложные JPA объекты на клиент не порождая кучу запросов к серверу.
А за библиотеку спасибо, раньше не видел, авторизация просто описана в базовом классе тестов.
Вы развели демагогию, в той ветке(автоваз) все описано, вы не хотите читать(точнее читаете то что нужно вам, вся картина видимо не интересна), пруф вы не скинули а вот вам выше скинули, но вы опять же игнорируете, вот про теслу www.vedomosti.ru/auto/news/2015/05/07/kvartalnii-ubitok-tesla-viros-v-tri-raza
megamozg.ru/post/10520, инвестиции могут быть длинными(к слову о лиотехе) на несколько десятилетий.
Приемлимым — это когда в конкретном государстве конкретная машина имеет соотношение цена/качество приемлимое для местного населения.
> Я правильно понимаю, что с вы предлагает мне, как гражданину РФ, предъявлять претензии по поводу сложившейся удручающей экономической ситуации внутри моей страны руководителям других государств, но не нашим?
Несомненно, почему бы вам как гражданину этой страны не написать письмо например в посольство Германии и задать вопрос по какой причине они ввели санкции против России. Вы как раз проявите свою гражданскую позицию не хуже, чем проголосовав на выборах.
> Не просто так. Что там с Лиотехом? Потратили почти 8 млрд. рублей и в итоге в прошлом году пришлось остановить завод. Или забыли уже историю с планшетами для школьников?
Можно пруф?(можно не на rt.com)
> О, да top.rbc.ru/business/30/03/2015/5519114a9a79476db2e0629b
Даже Tesla пока еще не приносит прибыли. Это показатель?
Обычные юзеры пишут что качество улучшилось, и по России довольно приемлимо.
geektimes.ru/post/250542/#comment_8373210 вот ветка обсуждений, довольно интересно
> Т.е. с АвтоВАЗом, Сколково и Роснано все ОК?
Ничто не идеально в этом мире. Роснано например спонсирует даурию, закрываем? Там у них на сайте можно почитать, довольно интересные проекты.
Сколково тоже самое, можно посмотреть на резидентов, есть как и дерьмо так и вполне неплохие фирмы.
> Тем, что инвестирование подразумевает под собой получение прибыли. В России люди принимающие решения об инвестировании бюджетных денег в ту или иную область затем не несут никакой ответственности за возрат инвестиций. В итоге имеем типичную для нашей страны ситуацию — деньги потрачены, результата нет, виновных тоже. С частными инвесторами такие трюки проварачивать сложнее.
Ну это нужно крайне глубоко в этом вопросе разбираться чтобы об этом так уверенно говорить.
> А санкции и отток капитала сами по себе что ли случились? Т.е. государство само себе (и гражданам) создало кучу проблем, а теперь пытается их героически решать?
Т.е. виновато только одно государство во всем? :) Ваша логика ясна. Другие же государства к этому отношение не имеют.
Ситуация когда лид читает ТЗ несколько раз и утверждает его вполне нормальна и адекватна. У меня был подобный опыт работы, где каждое звено тесно работало друг с другом(заказчик ставит задачу, аналитики от заказчика и исполнителя составляют тз, разработчики и тестировщики исполнителя оценивают полноту требований). В такой ситуации аналитик и лид часто немного погружались в обязанности друг дгуга(лид погружался в предметную область, а аналитик умел понимать элементарный код). Но в итоге это давало плюс, в большинстве случаев ТЗ оценивались адекватно. и делались в срок, а если были просчеты то они были минимальны.
В этой ситуации обязанности человека выше(менеджера) дать понять сотрудникам что все они делают общее дело и конфликты не приносят ничего кроме разрушения.
После этой работы я ушел на другую где связь между отделами отсутствует по сути, а аналитиков и тестировщиков нет вообще. Поэтому поставнока задачи в три предложения это нормально, остальное разраб додумывает сам. Издержки которые это все порождает катастрофичны, проект который можно сделать в течении 7-8 месяцев растягивается на 2+ года.
Демократическое государство как минимум конкурирует с государствами рядом с собой, а его сотрудники конечно же могут покинуть его, даже самым банальным способом перейдя границу. Не демократия создает конкуренцию, конкуренция есть всегда в жизни любого человека, это называется естественный отбор, его неплохо применяют в капитализме, но на самом деле это работает везде.
Другой пример: вас пырнули ножом в переулке, боль невыносима, в больнице вам дают опиум и пока вы под кайфом зашивают рану, в итоге вы выживаете и спокойной живете.
Религия это инструмент, а то кто и как его использует это уже другое дело. Можно использовать как наркотик, а можно как болеутоляющее. Важно это понимать и не впадать в крайности.
У Hibernate/JPA с производительностью все нормально, если уметь пользоваться. Просто на каждую возникающую проблему есть usecase, например n+1 проблема решается джоинами, либо дополнительным селектом.
Конечно есть ситуации когда приходится сидеть и разбираться что это он там копается и где это он там глючит и так далее. Но спустя время их почти не остается.
QueryDSL это типобезопасный язык запросов, все запросы(если они не динамические) компилируются, а следовательно не возникает проблем с опечатками, с забывчивостью в установке параметров запросов и так далее. Этот DSL может работать как поверх JDBC так и поверх JPA, и даже простых Java коллекций.
Больше всего проблем в связке Hibernate/JPA + Spring Data JPA + QueryDSL занимает Spring Data JPA, потому что API которое он предлагает по умолчанию очень слабое. Запросы пишутся либо с помощью аннотации Query, либо с помощью названия метода
findAllByAccount(String account)
либо с помощью стандартных средств Hibernate/JPA(я использую QueryDSL).
Получается что для простых ситуаций Spring Data подходит но для чего то посложней уже приходится искать более удобные варианты.
Ну и наконец касательно JDBC и производительности в целом, нет ничего лучше чистого JDBC(для Java) для написания запросов в плане производительности, тут у нас полная свобода пишем что хотим управляем кешированием зарпосов и так далее. Но часто нам нужен компромис между скоростью запросов и скоростью написания кода, в таком случае лучше начать с Spring Data и плавно переводить узкие места на JDBC. Например JPA очень плохо(во всяком случае я не нашел) работает с деревьями, нет штатных средств для Closure Table, Nested Sets и т.д. Тут мы используем чистый JDBC(у нас Closure Table в которой храним инфу о дереве).
Не хватает динамики в запросах.
В одном случае мне нужен такой запрос:
Query(«SELECT u FROM User u JOIN FETCH u.profile»)
В другом случае:
Query(«SELECT u FROM User u»)
А в третьем:
Query(«SELECT u FROM User u JOIN FETCH u.profile JOIN FETCH u.role»)
А к этому мне иногда еще нужна постраничная разбивка с сортировкой, иногда просто сортировка.
У меня тут два варианта решения проблемы:
1. Написать три разных метода и сверху каждого сделать аннотации Query.
2. Сделать один метод в котором динамически строить запрос на основе входных параметров(нужно ли вытаскивать профиль или нет, нужна ли роль или нет).
Второй вариант для меня предпочтительней потому что в рантайме я могу изменить запросы. Поэтому что бы так сделать мне приходится отдельно писать метод и в нем с помощью QueryDSL описывать логику выборки данных.
Варианты есть: jtwig.org, www.mitchellbosecke.com/pebble/home, github.com/greenlaw110/Rythm, github.com/jreijn/spring-comparing-template-engines.
Мы используем Pebble engine.
> Я посмотрел QueryDSL выглядит не очень. Опять же делать свой репозиторий это возврат к временам до Spring Data. И да с чего у вас каша будет? Вот определен у вас интерфейсы ваших репозиториев, ну размещайте туда все вызовы через аннотации. Ну все же можно. В итоге кода получается меньше и каши меньше.
Это возможно дело вкуса. Я попробую описать причины по которым сейчас я не вижу смысла в Spring Data JPA.
1. Короткие методы — не нужны, да первые ощущения от findAll положительные, но со временем понимаешь что тут у тебя метод findAll а вот тут Query, а там еще Specifications. А нужно чтобы все выглядело одинаково(или хочется).
2. Query не гибкий метод потому что иногда нужны динамические запросы. По итогу используем Criteria API, потому что Specifications нам явно не хватает.
В результате я смотрю на Spring Data JPA и думаю, а зачем мне весь этот сахар если он покрывается стандартным JPA полностью, а плюсов никаких не дает. Только каша из разных способов сделать одно и то же.
С другой стороны JPA мне тоже не хватает, потому что у него не все хорошо с нативными запросами, с джоинами по несвязанным таблицам и выборкой отдельных полей. В результате мы стали использовать QueryDSL который позволяет делать типобезопасные, универсальные запросы к JDBC,JPA и collections.
1. Вместо *.properties можно использовать *.yml — меньше текста, проще читать.
2. Я бы не советовал использовать Thymeleaf, он довольно медленный и у него КРАЙНЕ неудобный синтаксис для шаблонизатора.
3. Приложение можно запустить не только с помощью плагина Gradle но и из класса Application.
4. Gradle для нас оказался сыроват, мы используем менее гибкий но более стабильный Maven.
5. Spring boot умеет обновлять вашу схему в БД с помощью Hibernate. Свойство в application.properties, spring.jpa.hibernate.ddl-auto.
6. Я бы не советовал использовать Spring Data JPA. Ваш код 100% может обойтись без этого модуля, лучше возьмите QueryDSL и напишите всю прослойку Repository самостоятельно. Иначе в определенный момент вы получите кашу из методов-запросов, запросов Query, нативных запросов в SQL или с помощью JPA Criteria API. Если вы все таки решили использовать Spring Data JPA, то не поленитесь посмотреть исходники там есть интересные штуки типо AbstractPersistable.
Кстати по теме статьи, многое что вы описали я испытываю на собственной шкуре, в плане удобства рабочего места. Тут тебе и невозможность открыть окно(кондиционеры же) и дискомфорт от работы с некоторыми коллегами(например некоторые громко говорят, а некоторые любят яркий свет и т.д.). И невозможность установить софт который хочу я, например Linux. И высокие уровень CO2 и невозможность компании хоть что то с этим сделать, ведь офис снимается.
А за библиотеку спасибо, раньше не видел, авторизация просто описана в базовом классе тестов.
megamozg.ru/post/10520, инвестиции могут быть длинными(к слову о лиотехе) на несколько десятилетий.
Приемлимым — это когда в конкретном государстве конкретная машина имеет соотношение цена/качество приемлимое для местного населения.
> Я правильно понимаю, что с вы предлагает мне, как гражданину РФ, предъявлять претензии по поводу сложившейся удручающей экономической ситуации внутри моей страны руководителям других государств, но не нашим?
Несомненно, почему бы вам как гражданину этой страны не написать письмо например в посольство Германии и задать вопрос по какой причине они ввели санкции против России. Вы как раз проявите свою гражданскую позицию не хуже, чем проголосовав на выборах.
Можно пруф?(можно не на rt.com)
> О, да top.rbc.ru/business/30/03/2015/5519114a9a79476db2e0629b
Даже Tesla пока еще не приносит прибыли. Это показатель?
Обычные юзеры пишут что качество улучшилось, и по России довольно приемлимо.
geektimes.ru/post/250542/#comment_8373210 вот ветка обсуждений, довольно интересно
> Т.е. с АвтоВАЗом, Сколково и Роснано все ОК?
Ничто не идеально в этом мире. Роснано например спонсирует даурию, закрываем? Там у них на сайте можно почитать, довольно интересные проекты.
Сколково тоже самое, можно посмотреть на резидентов, есть как и дерьмо так и вполне неплохие фирмы.
> Тем, что инвестирование подразумевает под собой получение прибыли. В России люди принимающие решения об инвестировании бюджетных денег в ту или иную область затем не несут никакой ответственности за возрат инвестиций. В итоге имеем типичную для нашей страны ситуацию — деньги потрачены, результата нет, виновных тоже. С частными инвесторами такие трюки проварачивать сложнее.
Ну это нужно крайне глубоко в этом вопросе разбираться чтобы об этом так уверенно говорить.
> А санкции и отток капитала сами по себе что ли случились? Т.е. государство само себе (и гражданам) создало кучу проблем, а теперь пытается их героически решать?
Т.е. виновато только одно государство во всем? :) Ваша логика ясна. Другие же государства к этому отношение не имеют.
В этой ситуации обязанности человека выше(менеджера) дать понять сотрудникам что все они делают общее дело и конфликты не приносят ничего кроме разрушения.
После этой работы я ушел на другую где связь между отделами отсутствует по сути, а аналитиков и тестировщиков нет вообще. Поэтому поставнока задачи в три предложения это нормально, остальное разраб додумывает сам. Издержки которые это все порождает катастрофичны, проект который можно сделать в течении 7-8 месяцев растягивается на 2+ года.
Религия это инструмент, а то кто и как его использует это уже другое дело. Можно использовать как наркотик, а можно как болеутоляющее. Важно это понимать и не впадать в крайности.
Конечно есть ситуации когда приходится сидеть и разбираться что это он там копается и где это он там глючит и так далее. Но спустя время их почти не остается.
QueryDSL это типобезопасный язык запросов, все запросы(если они не динамические) компилируются, а следовательно не возникает проблем с опечатками, с забывчивостью в установке параметров запросов и так далее. Этот DSL может работать как поверх JDBC так и поверх JPA, и даже простых Java коллекций.
Больше всего проблем в связке Hibernate/JPA + Spring Data JPA + QueryDSL занимает Spring Data JPA, потому что API которое он предлагает по умолчанию очень слабое. Запросы пишутся либо с помощью аннотации Query, либо с помощью названия метода
findAllByAccount(String account)
либо с помощью стандартных средств Hibernate/JPA(я использую QueryDSL).
Получается что для простых ситуаций Spring Data подходит но для чего то посложней уже приходится искать более удобные варианты.
Ну и наконец касательно JDBC и производительности в целом, нет ничего лучше чистого JDBC(для Java) для написания запросов в плане производительности, тут у нас полная свобода пишем что хотим управляем кешированием зарпосов и так далее. Но часто нам нужен компромис между скоростью запросов и скоростью написания кода, в таком случае лучше начать с Spring Data и плавно переводить узкие места на JDBC. Например JPA очень плохо(во всяком случае я не нашел) работает с деревьями, нет штатных средств для Closure Table, Nested Sets и т.д. Тут мы используем чистый JDBC(у нас Closure Table в которой храним инфу о дереве).