JPA und Hibernate - Kriterien vs. JPQL oder HQL

Was sind die Vor- und Nachteile der Verwendung von Kriterien oder HQL ? Die Kriterien-API ist eine nette objektorientierte Methode, um Abfragen im Ruhezustand auszudrücken. Manchmal sind Kriterienabfragen jedoch schwieriger zu verstehen / zu erstellen als HQL.

Wann verwenden Sie Kriterien und wann HQL? Was bevorzugen Sie in welchen Anwendungsfällen? Oder ist es nur Geschmackssache?

Ich bevorzuge hauptsächlich Kriterienabfragen für dynamische Abfragen. Zum Beispiel ist es viel einfacher, eine Reihenfolge dynamisch hinzuzufügen oder einige Teile (z. B. Einschränkungen) abhängig von bestimmten Parametern wegzulassen.

Andererseits verwende ich HQL für statische und komplexe Abfragen, weil es viel einfacher ist, HQL zu verstehen / zu lesen. Außerdem ist HQL meiner Meinung nach etwas leistungsfähiger, z. B. für verschiedene Join-Typen.

Es gibt einen Leistungsunterschied zwischen HQL und KriterienQuery. Jedes Mal, wenn Sie eine Abfrage mit KriterienQuery auslösen, wird ein neuer Alias ​​für den Tabellennamen erstellt, der im zuletzt abgefragten Cache für eine Datenbank nicht berücksichtigt wird. Dies führt zu einem Overhead beim Kompilieren des generierten SQL, dessen Ausführung mehr Zeit in Anspruch nimmt.

In Bezug auf Abrufstrategien [http://www.hibernate.org/315.html]

• Kriterien berücksichtigen die Faulheitseinstellungen in Ihren Zuordnungen und garantieren, dass das, was Sie laden möchten, geladen wird. Dies bedeutet, dass eine Kriterienabfrage möglicherweise zu mehreren sofortigen SQL-SELECT-Anweisungen führt, um den Untergraphen mit allen nicht verzögerten zugeordneten Zuordnungen und Sammlungen abzurufen. Wenn Sie das "Wie" und sogar das "Was" ändern möchten, verwenden Sie setFetchMode (), um das Abrufen äußerer Verknüpfungen für eine bestimmte Sammlung oder Zuordnung zu aktivieren oder zu deaktivieren. Kriterienabfragen berücksichtigen auch vollständig die Abrufstrategie (Join vs Select vs Subselect).
• HQL respektiert die Faulheitseinstellungen in Ihren Zuordnungen und garantiert, dass das, was Sie laden möchten, geladen wird. Dies bedeutet, dass eine HQL-Abfrage möglicherweise zu mehreren SQL-Sofort-SELECT-Anweisungen führt, um den Untergraphen mit allen nicht verzögerten zugeordneten Zuordnungen und Sammlungen abzurufen. Wenn Sie das "Wie" und sogar das "Was" ändern möchten, verwenden Sie LEFT JOIN FETCH, um das Abrufen von Outer-Joins für eine bestimmte Sammlung oder nullbare Viele-zu-Eins- oder Eins-zu-Eins-Zuordnungen zu aktivieren, oder JOIN FETCH, um dies zu aktivieren Abrufen der inneren Verknüpfung für eine nicht nullfähige Viele-zu-Eins- oder Eins-zu-Eins-Zuordnung. HQL-Abfragen berücksichtigen keine im Mapping-Dokument definierten fetch = "join".

Criteria ist eine objektorientierte API, während HQL die Verkettung von Zeichenfolgen bedeutet. Das heißt, alle Vorteile der Objektorientierung gelten:

1. Wenn alles andere gleich ist, ist die OO-Version etwas weniger fehleranfällig. Jede alte Zeichenfolge kann an die HQL-Abfrage angehängt werden, während nur gültige Kriterienobjekte in einen Kriterienbaum aufgenommen werden können. Tatsächlich sind die Kriterienklassen eingeschränkter.
2. Mit der automatischen Vervollständigung ist das OO besser erkennbar (und damit zumindest für mich einfacher zu bedienen). Sie müssen sich nicht unbedingt merken, welche Teile der Abfrage wohin gehen. Die IDE kann Ihnen helfen
3. Sie müssen sich auch nicht an die Einzelheiten der Syntax erinnern (z. B. welche Symbole wohin gehen). Sie müssen lediglich wissen, wie Sie Methoden aufrufen und Objekte erstellen.

Da HQL SQL sehr ähnlich ist (was die meisten Entwickler bereits sehr gut kennen), haben diese Argumente, an die man sich nicht erinnern muss, nicht so viel Gewicht. Wenn HQL anders wäre, wäre dies wichtiger.

Normalerweise verwende ich Kriterien, wenn ich nicht weiß, welche Eingaben für welche Daten verwendet werden. Wie bei einem Suchformular, bei dem der Benutzer 1 bis 50 Elemente eingeben kann und ich nicht weiß, wonach er suchen wird. Es ist sehr einfach, mehr an die Kriterien anzuhängen, während ich überprüfe, wonach der Benutzer sucht. Ich denke, es wäre etwas schwieriger, unter diesen Umständen eine HQL-Abfrage zu stellen. HQL ist großartig, wenn ich genau weiß, was ich will.

HQL ist viel einfacher zu lesen, mit Tools wie dem Eclipse Hibernate-Plugin einfacher zu debuggen und einfacher zu protokollieren. Kriterienabfragen eignen sich besser zum Erstellen dynamischer Abfragen, bei denen ein Großteil des Verhaltens zur Laufzeit bestimmt wird. Wenn Sie SQL nicht kennen, könnte ich die Verwendung von Kriterienabfragen verstehen, aber insgesamt bevorzuge ich HQL, wenn ich weiß, was ich im Voraus möchte.

Kriterien sind die einzige Möglichkeit, natürliche Schlüsselsuchen anzugeben, die die spezielle Optimierung im Abfragecache der zweiten Ebene nutzen. HQL hat keine Möglichkeit, den erforderlichen Hinweis anzugeben.

Weitere Informationen finden Sie hier:

• http://tech.puredanger.com/2009/07/10/hibernate-query-cache/

Kriterien Api ist eines der guten Konzepte von Hibernate. Meiner Ansicht nach sind dies die wenigen Punkte, anhand derer wir zwischen HQL und Criteria Api unterscheiden können

1. HQL soll sowohl Auswahl- als auch Nichtauswahloperationen für die Daten ausführen. Kriterien dienen jedoch nur zur Auswahl der Daten. Wir können keine Nichtauswahloperationen unter Verwendung von Kriterien ausführen.
2. HQL eignet sich zum Ausführen statischer Abfragen, während als Kriterien zum Ausführen dynamischer Abfragen geeignet ist
3. HQL unterstützt das Paginierungskonzept nicht , aber wir können die Paginierung mit Kriterien erreichen.
4. Die Ausführung von Kriterien dauerte früher länger als bei HQL.
5. Mit Criteria sind wir mit SQL Injection aufgrund seiner dynamischen Abfragegenerierung sicher, aber in HQL gibt es keinen Safe vor SQL Injection, da Ihre Abfragen entweder fest oder parametrisiert sind

Um das Beste aus beiden Welten zu nutzen, sollten Querydsl , die Expressivität und Prägnanz von HQL sowie die Dynamik von Kriterien in Betracht gezogen werden .

Querydsl unterstützt JPA / Hibernate, JDO, SQL und Collections.

Ich bin der Betreuer von Querydsl, daher ist diese Antwort voreingenommen.

Für mich ist Criteria ein ziemlich leicht zu verstehendes und dynamisches Abfragen. Aber der Fehler, den ich bisher sage, ist, dass es alle Beziehungen mit vielen Einsen usw. lädt, weil wir nur drei Arten von FetchModes haben, nämlich Select, Proxy und Default, und in all diesen Fällen lädt er viele Einsen (möglicherweise irre ich mich, wenn dies hilft mich raus :))

Das zweite Problem mit Criteria ist, dass es ein vollständiges Objekt lädt. Wenn ich also nur EmpName eines Mitarbeiters laden möchte, wird es nicht mit diesem Instant angezeigt. Es wird ein vollständiges Employee-Objekt erstellt, und ich kann EmpName daraus abrufen, da es wirklich schlecht funktioniert Berichterstattung . Wo als HQL nur geladen wurde (Assoziationen / Relationen wurden nicht geladen), was Sie wollen, erhöhen Sie die Leistung um ein Vielfaches.

Ein Merkmal von Criteria ist, dass es Sie aufgrund seiner dynamischen Abfragegenerierung vor SQL Injection schützt, wobei wie in HQL Ihre Abfragen entweder fest oder parametrisiert sind und daher nicht vor SQL Injection sicher sind.

Auch wenn Sie HQL in ur aspx.cs-Dateien schreiben, sind Sie eng mit ur DAL verbunden.

Insgesamt bin ich zu dem Schluss gekommen, dass es Orte gibt, an denen Sie ohne HQL-ähnliche Berichte nicht leben können. Verwenden Sie sie daher, sonst sind die Kriterien einfacher zu verwalten.

Kriterien-API

Die Kriterien-API eignet sich besser für dynamisch generierte Abfragen. Wenn Sie also WHERE-Klauselfilter, JOIN-Klauseln oder die ORDER BY-Klausel oder die Projektionsspalten hinzufügen möchten, kann Ihnen die Kriterien-API dabei helfen, die Abfrage dynamisch so zu generieren, dass auch SQL Injection-Angriffe verhindert werden .

Auf der anderen Seite sind Kriterienabfragen weniger aussagekräftig und können sogar zu sehr komplizierten und ineffizienten SQL-Abfragen führen, wie in diesem Artikel erläutert .

JPQL und HQL

JPQL ist die Abfragesprache für JPA-Standardentitäten, während HQL JPQL erweitert und einige Hibernate-spezifische Funktionen hinzufügt.

JPQL und HQL sind sehr ausdrucksstark und ähneln SQL. Im Gegensatz zur Criteria API erleichtern JPQL und HQL die Vorhersage der zugrunde liegenden SQL-Abfrage, die vom JPA-Anbieter generiert wird. Es ist auch viel einfacher, die eigenen HQL-Abfragen zu überprüfen als die Kriterien.

Es ist erwähnenswert, dass die Auswahl von Entitäten mit JPQL- oder Kriterien-API sinnvoll ist, wenn Sie sie ändern müssen. Ansonsten ist eine DTO-Projektion eine viel bessere Wahl.

Fazit

Wenn Sie die Struktur der Entitätsabfrage nicht ändern müssen, verwenden Sie JPQL oder HQL. Wenn Sie die Filter- oder Sortierkriterien oder die Projektion ändern müssen, verwenden Sie die Kriterien-API.

Nur weil Sie JPA oder Hibernate verwenden, bedeutet dies nicht, dass Sie kein natives SQL verwenden sollten. SQL-Abfragen sind sehr nützlich und JPQL und die Kriterien-API sind kein Ersatz für SQL. In diesem Artikel finden Sie weitere Informationen zu diesem Thema.

Für mich ist der größte Gewinn bei Criteria die Beispiel-API, bei der Sie ein Objekt übergeben können und der Ruhezustand eine Abfrage basierend auf diesen Objekteigenschaften erstellt.

Abgesehen davon hat die Kriterien-API ihre Macken (ich glaube, das Hibernate-Team überarbeitet die API) wie:

• Ein Kriterien.createAlias ​​("obj") erzwingt einen inneren Join anstelle eines möglichen äußeren Joins
• Sie können nicht zweimal denselben Alias ​​erstellen
• Einige SQL-Klauseln haben kein einfaches Kriterium (wie eine Unterauswahl).
• etc.

Ich verwende normalerweise HQL, wenn ich Abfragen ähnlich wie SQL möchte (Löschen von Benutzern, bei denen status = 'blockiert'), und ich verwende Kriterien, wenn ich kein Anhängen von Zeichenfolgen verwenden möchte.

Ein weiterer Vorteil von HQL ist, dass Sie alle Ihre Abfragen vorab definieren und sogar in eine Datei oder so auslagern können.

Criteria API bietet eine bestimmte Funktion, die weder SQL noch HQL bieten. dh. Es ermöglicht die Überprüfung der Kompilierungszeit einer Abfrage.

Am Anfang haben wir in unserer Anwendung hauptsächlich Kriterien verwendet, aber nachdem sie aufgrund von Leistungsproblemen durch HQL ersetzt wurde.
Hauptsächlich verwenden wir sehr komplexe Abfragen mit mehreren Verknüpfungen, was zu mehreren Abfragen in Kriterien führt, aber in HQL sehr optimiert ist.
Der Fall ist, dass wir nur einige Eigenschaften für ein bestimmtes Objekt verwenden und keine vollständigen Objekte. Bei Criteria war das Problem auch die Verkettung von Zeichenfolgen.
Angenommen, Sie müssen den (name || ' ' || surname)Vor- und Nachnamen des Benutzers in HQL anzeigen, dies ist recht einfach , in Crteria ist dies jedoch nicht möglich.
Um dies zu überwinden, verwendeten wir ResultTransormers, bei denen es Methoden gab, bei denen eine solche Verkettung für das erforderliche Ergebnis implementiert wurde.
Heute verwenden wir hauptsächlich HQL wie folgt:

String hql = "select " +
            "c.uuid as uuid," +
            "c.name as name," +
            "c.objective as objective," +
            "c.startDate as startDate," +
            "c.endDate as endDate," +
            "c.description as description," +
            "s.status as status," +
            "t.type as type " +
            "from " + Campaign.class.getName() + " c " +
            "left join c.type t " +
            "left join c.status s";

Query query =  hibernateTemplate.getSessionFactory().getCurrentSession().getSession(EntityMode.MAP).createQuery(hql);
query.setResultTransformer(Transformers.ALIAS_TO_ENTITY_MAP);
return query.list();

In unserem Fall handelt es sich bei den zurückgegebenen Datensätzen also um Karten der benötigten Eigenschaften.

• HQL soll sowohl Auswahl- als auch Nichtauswahloperationen für die Daten ausführen. Kriterien dienen jedoch nur zur Auswahl der Daten. Wir können keine Nichtauswahloperationen unter Verwendung von Kriterien ausführen
• HQL eignet sich zum Ausführen statischer Abfragen, während als Kriterien zum Ausführen dynamischer Abfragen geeignet ist
• HQL unterstützt das Paginierungskonzept nicht, aber wir können die Paginierung mit Kriterien erreichen
• Die Ausführung von Kriterien dauerte früher länger als bei HQL
• Mit Criteria sind wir mit SQL Injection aufgrund seiner dynamischen Abfragegenerierung sicher, aber in HQL gibt es keinen Safe vor SQL Injection, da Ihre Abfragen entweder fest oder parametrisiert sind.

Quelle

Kriterienabfrage für dynamisch können wir eine Abfrage basierend auf unseren Eingaben erstellen. Im Fall einer Hql-Abfrage ist die statische Abfrage, sobald wir sie erstellt haben, können wir die Struktur der Abfrage nicht ändern.

Ich möchte hier kein totes Pferd treten, aber es ist wichtig zu erwähnen, dass Kriterienabfragen jetzt veraltet sind. Verwenden Sie HQL.

Ich bevorzuge auch Kriterienabfragen für dynamische Abfragen. Aber ich bevorzuge hql zum Löschen von Abfragen, zum Beispiel, wenn alle Datensätze aus der untergeordneten Tabelle für die übergeordnete ID 'xyz' gelöscht werden. Dies wird von HQL leicht erreicht, aber für die Kriterien-API müssen wir zuerst n Anzahl der Löschabfragen auslösen, wobei n die Anzahl der untergeordneten Abfragen ist Tabellendatensätze.

Die meisten Antworten hier sind irreführend und erwähnen, dass sie Criteria Querieslangsamer sind als HQL, was eigentlich nicht der Fall ist.

Wenn Sie tief eintauchen und einige Tests durchführen, werden Sie feststellen, dass Kriterienabfragen viel besser abschneiden als reguläres HQL .

Und auch mit Criteria Query erhalten Sie eine objektorientierte Steuerung, die mit HQL nicht vorhanden ist .

Für weitere Informationen lesen Sie diese Antwort hier .

Es geht auch anders. Am Ende habe ich einen HQL-Parser erstellt, der auf der ursprünglichen Syntax im Ruhezustand basiert, sodass zuerst der HQL analysiert und dann dynamische Parameter dynamisch eingefügt oder automatisch einige allgemeine Filter für die HQL-Abfragen hinzugefügt werden können. Es funktioniert super!

Dieser Beitrag ist ziemlich alt. Die meisten Antworten beziehen sich auf Ruhezustandskriterien, nicht auf JPA-Kriterien. JPA 2.1 fügte CriteriaDelete / CriteriaUpdate und EntityGraph hinzu, die steuern, was genau abgerufen werden soll. Die Kriterien-API ist besser, da Java OO ist. Deshalb wird JPA erstellt. Wenn JPQL kompiliert wird, wird es in den AST-Baum (OO-Modell) übersetzt, bevor es in SQL übersetzt wird.

HQL kann Sicherheitsbedenken wie SQL-Injection verursachen.