JPA и в спящем режиме - критерии по сравнению с JPQL или HQL
В Java все переменные, которые вы объявляете, на самом деле являются «ссылками» на объекты (или примитивы), а не самими объектами.
При попытке выполнить один метод объекта , ссылка просит живой объект выполнить этот метод. Но если ссылка ссылается на NULL (ничего, нуль, void, nada), то нет способа, которым метод будет выполнен. Тогда runtime сообщит вам об этом, выбросив исключение NullPointerException.
Ваша ссылка «указывает» на нуль, таким образом, «Null -> Pointer».
Объект живет в памяти виртуальной машины пространство и единственный способ доступа к нему - использовать ссылки this. Возьмем этот пример:
public class Some {
private int id;
public int getId(){
return this.id;
}
public setId( int newId ) {
this.id = newId;
}
}
И в другом месте вашего кода:
Some reference = new Some(); // Point to a new object of type Some()
Some otherReference = null; // Initiallly this points to NULL
reference.setId( 1 ); // Execute setId method, now private var id is 1
System.out.println( reference.getId() ); // Prints 1 to the console
otherReference = reference // Now they both point to the only object.
reference = null; // "reference" now point to null.
// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );
// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...
Это важно знать - когда больше нет ссылок на объект (в пример выше, когда reference и otherReference оба указывают на null), тогда объект «недоступен». Мы не можем работать с ним, поэтому этот объект готов к сбору мусора, и в какой-то момент VM освободит память, используемую этим объектом, и выделит другую.
9 ответов
Я главным образом предпочитаю Запросы Критериев для динамических запросов. Например, намного легче добавить некоторое упорядочивание динамично или оставить некоторые части (например, ограничения) в зависимости от некоторого параметра.
, С другой стороны, я использую HQL для статических и сложных запросов, потому что намного легче понимать/читать HQL. Кроме того, HQL немного более мощен, я думаю, например, для различных типов соединения.
Для меня самая большая победа на Критериях является API В качестве примера, куда можно передать объект и быть в спящем режиме, создаст запрос на основе тех свойств объектов.
Помимо этого, API критериев имеет свои причуды (я полагаю, что быть в спящем режиме команда переделывает API), как:
- criteria.createAlias ("obj") вызывает внутреннее объединение вместо возможного внешнего объединения
- , Вы не можете создать тот же псевдоним два раза
- , некоторые sql пункты не имеют никакого простого дубликата критериев (как подвыбор)
- и т.д.
, я склонен использовать HQL, когда я хочу запросы, подобные sql (удалите от Пользователей, где состояние ='blocked'), и я склонен использовать критерии, когда я не хочу использовать строковое добавление.
Другое преимущество HQL состоит в том, что можно определить все запросы перед рукой, и даже воплотить их в файл или около этого.
HQL намного легче считать, легче отладить инструменты использования как Eclipse В спящем режиме плагин, и легче зарегистрироваться. Запросы критериев лучше для создания динамических запросов, где большое поведение определяется во времени выполнения. Если Вы не знаете SQL, я мог бы понять запросы Критериев использования, но в целом я предпочитаю HQL, если я знаю то, что я хочу заранее.
Я обычно использую Критерии, когда я не знаю то, что исходные данные будут использоваться на который части данных. Как на поисковой форме, где пользователь может ввести любой из 1 - 50 объектов и я не знаю то, что они будут искать. Очень легко просто добавить больше к критериям, поскольку я прохожу проверку то, что ищет пользователь. Я думаю, что это было бы немного более неприятно для помещения запроса HQL в то обстоятельство. HQL является большим хотя, когда я знаю точно, что я хочу.
Критерии являются объектно-ориентированным API, в то время как HQL означает конкатенацию строк. Это означает, что все преимущества объектно-ориентированности применяются:
- Все остальное являющееся равным, версия OO несколько менее подвержена ошибке. Любая старая строка могла быть добавлена в запрос HQL, тогда как только допустимые объекты Критериев могут превратить его в дерево Критериев. Эффективно, классы Критериев более ограничиваются.
- С автоматическим заполнением, OO является более поддающимся обнаружению (и таким образом легче использовать для меня, по крайней мере). Необходимо не обязательно помнить, какие части запроса идут где; IDE может помочь Вам
- , Вы также не должны помнить подробные сведения синтаксиса (как который символы идут где). Все, что необходимо знать, - то, как назвать методы и создать объекты.
, Так как HQL очень похож на SQL (который большинство devs очень хорошо уже знает), тогда, они "не должны помнить, что" аргументы не несут столько же веса. Если бы HQL более отличался, то это было бы большим количеством importatnt.
Существует различие в терминах производительности между HQL и criteriaQuery, каждый раз Вы запускаете запрос с помощью criteriaQuery, это создает новый псевдоним для имени таблицы, которое не отражается в последнем запрошенном кэше ни для какого DB. Это приводит к издержкам компиляции сгенерированного SQL, занимая больше времени для выполнения.
Относительно выбирающих стратегий [http://www.hibernate.org/315.html]
- Критерии уважают настройки лени в Ваших отображениях и гарантируют, что то, что Вы хотите загруженный, загружается. Это означает, что один запрос Критериев мог бы привести к нескольким SQL непосредственные операторы SELECT для выборки подграфа со всеми неленивыми отображенными ассоциациями и наборами. Если Вы хотите измениться, "как" и даже, "какой", используйте setFetchMode (), чтобы включить или отключить выборку внешнего объединения для конкретного набора или ассоциации. Запросы критериев также полностью уважают выбирающую стратегию (соединение по сравнению с выбором по сравнению с подвыбором).
- HQL уважает настройки лени в Ваших отображениях и гарантирует, что то, что Вы хотите загруженный, загружается. Это означает, что один запрос HQL мог бы привести к нескольким SQL непосредственные операторы SELECT для выборки подграфа со всеми неленивыми отображенными ассоциациями и наборами. Если Вы хотите измениться, "как" и даже, "какой", используйте ОСТАВЛЕННУЮ ВЫБОРКУ СОЕДИНЕНИЯ, чтобы позволить выборке внешнего объединения для конкретного набора или nullable many-one или однозначной связи или ВЫБОРКИ СОЕДИНЕНИЯ включить выборку внутреннего объединения для не допускающего NULL-значения many-one или однозначной связи. Запросы HQL не уважают выборки = "соединение", определенное в отображающемся документе.
Для меня Критерии довольно легко понять и сделать динамические запросы. Но недостаток, о котором я говорю, заключается в том, что он загружает все отношения много-один и т.д., потому что у нас есть только три типа FetchModes, то есть Select, Proxy и Default, и во всех этих случаях он загружает много-один (может быть, я ошибаюсь, если так поможет меня :))
2-я проблема с критериями заключается в том, что он загружает полный объект, т.е. если я хочу просто загрузить EmpName сотрудника, он не придет с этим insted, он придумал полный объект Employee, и я могу получить от него EmpName из-за этого он действительно плохо работает в отчетах . где, поскольку HQL просто загружает (не загружает ассоциации / отношения), что вы хотите, увеличивайте производительность во много раз.
Criteria are the only way to specify natural key lookups that take advantage of the special optimization in the second level query cache. HQL does not have any way to specify the necessary hint.
You can find some more info here:
Для того, чтобы использовать лучшее из обоих миров, выразительность и лаконичность HQL и динамическую природу Критериев рассмотрим использование Querydsl .
Querydsl поддерживает JPA/Hibernate, JDO, SQL и коллекции.
Я являюсь сопровождающим Querydsl, поэтому данный ответ является предвзятым.