Java EE, jsf, jpa

JAVA PERSISTENCE CRITERIA

L’API CRITERIA

L’API Criteria Java Persistence est utilisée pour définir des requêtes dynamiques à travers la construction d'objets de définition de requête orientée objets, plutôt que l'utilisation de l'approche basée sur la chaîne JPQL. L'API Criteria permet de construire des requêtes dynamiques dont la programmation offre une meilleure intégration avec le Langage Java et une approche orientée chaîne de 4ème génération.

L’API Criteria a deux modes, le mode de type restreint, et le mode non-typée. Le mode de type restreint utilise un ensemble de JPA méta-modèle généré par classe pour définir les attributs interrogeables d'une classe, (voir méta modèle). Le mode non-typé utilise des chaînes pour référencer les attributs d'une classe.

L'API Criteria est seulement pour les requêtes dynamiques, et ne peut pas être utilisé dans les métadonnées ou des requêtes nommées.

Les requêtes Criteria sont des requêtes dynamiques, elles ne sont donc pas aussi performantes que les requêtes statiques nommées, ou même les paramètres dynamiques de JPQL qui peuvent bénéficier d'un cache d'analyse de certains fournisseurs JPA.

L’API Criteria a été ajoutée dans JPA 2.0.

L'API de critères de support de suppression et de mise à jour a été ajoutée dans

JPA 2.1.

CriteriaBuilder

CriteriaBuilder est l'interface principale dans l'API Criteria. Un CriteriaBuilder est obtenu à partir d'un EntityManager ou un EntityManagerFactory utilisant l'API getCriteriaBuilder (). CriteriaBuilder est utilisé pour construire des objets de CriteriaQuery et leurs expressions. L’API Criteria ne supporte actuellement que des requêtes de sélection (SELECT).

CriteriaBuilder définit l’ API pour créer des objets CriteriaQuery:

CreateQuery () - Crée un CriteriaQuery.

CreateQuery (Classe) - Crée un CriteriaQuery utilisant les génériques pour éviter de lancer classe des résultats.

CreateTupleQuery () - Crée un CriteriaQuery qui retourne la carte comme des objets Tuple, à la place de l'objet tableau pour les requêtes multiselect.

CreateCriteriaDelete (Classe) - Crée un CriteriaDelete pour supprimer un lot d'objets directement sur la base de données (JPA 2.1).
CreateCriteriaUpdate(Classe) - Crée un CriteriaUpdate pour mettre à jour un lot d'objets directement sur la base de données (JPA 2.1).

CriteriaBuilder définit également toutes les opérations de comparaison prises en charge et des fonctions utilisées pour définir les clauses de la requête.

CRITERIAQUERY

CriteriaQuery définit une requête de Sélection de base de données. Pour tous les modèles CriteriaQuery, des clauses de requête d’un JPQL sont sélectionnées.

Les éléments d'un CriteriaQuery ne peuvent pas être utilisés dans d'autres CriteriaQuery. Un CriteriaQuery est utilisé avec l'API EntityManager CreateQuery () pour créer une requête JPA.

CriteriaQuery définit les clauses et les options suivantes:

§ distinct (booléen) - Définit si la requête doit filtrer les résultats en double (faux par défaut). Si une jointure d’une relation de collecte est utilisée, distinct doit être utilisé pour éviter des résultats en double.

§ from (classe) - Définit et renvoie un élément de la clause from de la requête pour la classe d'entité. Au moins un élément est nécessaire pour que la requête soit valide.

§ from (type d'entité) - Définit et renvoie un élément de la clause du méta-modèle entité type. Au moins un élément est nécessaire pour que la requête soit valide.

§ select (Sélection) - Définit la clause select de la requête. S'il n'est pas défini, la première racine sera choisi par défaut.

§ multiselect (Sélection ...), multiselect (Liste <Sélection>) - Définit une requête de multi-sélection.

§ where (Expression), where (prédicat ...) - Définition de la clause WHERE. Par défaut tous les cas de la classe sont sélectionnés.

§ orderBy (commande ...), orderBy (Liste <Order>) - Définit la clause de l'ordre de requête. Par défaut, les résultats ne sont pas ordonnés.

§ Group by(Expression ...), group by (List <expression>) - Définit le groupe de requêtes par article. par défaut les résultats ne sont pas regroupés.

§ having (Expression),having (prédicat ...) - Définition de la clause having de la requête. Having permet de regrouper les résultats à filtrer.

§ subquery (Classe) - Crée une sous-requête pour être utilisé dans l'une des autres clauses.

Les expressions, prédicates, order sont des éléments définis en utilisant l'API CriteriaBuilder et l’expressions dérivé de la racine à partir d'éléments.

SELECTION

Une sélection définit ce qui est sélectionné par une requête. Une sélection peut être n'importe quelle expression de l'objet, une expression d’attribut, une fonction, une sous-sélection, un constructeur ou la fonction d'agrégation. Un alias peut être défini pour une Sélection à l'aide de l'API alias ().

LES FONCTIONS D’AGREGATION

Les fonctions d'agrégation peuvent inclure des informations de synthèse sur un ensemble d'objets. Ces fonctions peuvent être utilisées pour renvoyer un seul résultat, ou peut être utilisées avec un groupby pour renvoyer plusieurs résultats.

Les fonctions d'agrégation sont définies sur CriteriaBuilder et comprennent:

§ max (expression) - Retourne la valeur maximale pour l'ensemble des résultats. Utilisé pour les types numériques.

§ greatest (Expression) – Retourne la valeur maximale pour l'ensemble des résultats. Utilisé pour les types non-numériques.

§ min (expression) - Retourne la valeur minimale pour tous les résultats. Utilisé pour les types numériques.

§ least (Expression) - Retourne la valeur minimale pour tous les résultats. Utilisé pour les types non-numériques.

§ avg (expression) - Retourne la moyenne de tous les résultats. Un double est renvoyé.

§ sum (Expression) - Retourne la somme de tous les résultats.

§ sumAsLong(Expression) - Retourne la somme de tous les résultats. Un Long est retourné.

§ sumAsDouble(Expression) - Retourne la somme de tous les résultats. Un double est renvoyé.

§ count (expression) - Retourne le nombre de résultats. les valeurs NULL ne sont pas comptées. Un Long est retourné.

§ countDistinct (Expression) - Retourne le calcul de l'ensemble des résultats distincts. les valeurs NULL ne sont pas comptées. un Long est retourné.

CONSTRUCTOR

L'opérateur construct dans CriteriaBuilder peut être utilisé avec une classe et les valeurs pour retourner les données objets à partir d'une requête Criteria. Ceux-ci ne seront pas gérés par les objets, et les classes doivent définir un constructeur qui correspond aux arguments et types. Les Requêtes constructeur peuvent être utilisées pour sélectionner des données partielles ou des rapports de données sur les objets et récupérer une instance de la classe à la place d'un objet tableau ou tuple.

FROM

La clause from de la requête définit ce qui est demandé. La clause from est définie en utilisant l’API from dans CriteriaQuery. Un objet root (racine) est retourné à partir de from, ce qui représente l'objet dans le cadre de la requête.

Une racine met également en œuvre from, et Path.from définit une variable dans la clause from et permet une jointure.

Path définit une valeur d'attribut et permet la traversée des attributs imbriqués.

Les requêtes Criteria permettent de nombreux niveaux de racines objets. Il faut être prudent lors de cette opération, car il peut conduire à des produits cartésiens de deux tables. La clause where doit s'assurer que les deux objets sont reliés d'une manière quelconque.

JOIN

L’opération join peut être utilisée sur un objet from de sorte à obtenir une relation à utiliser dans la requête. join ne veut pas dire que les relations doivent être récupérés, aussi les objets liés dans le résultat utilisent l’opération fetch.

L'opération join peut être utilisé avec les correspondances OneToMany, ManyToOne, OneToMany, ManyToMany et ElementCollection. Lorsqu'il est utilisé avec une relation de collection, vous pouvez joindre les mêmes relations à plusieurs reprises pour interroger plusieurs valeurs indépendantes.

FETCH

L'opération fetch peut être utilisée sur un objet from pour récupérer les objets connexes en une seule requête. Cela évite des requêtes supplémentaires pour chacune des relations de l'objet, et veille à ce que les relations soient récupérées.

Il faut être prudent dans l'utilisation d'un Fetch dans la clause where car il peut affecter les données renvoyées pour le résultat des relations de l'objet. Les objets doivent normalement toujours avoir les mêmes données, quel que soit la où ils ont été interrogés, ce qui est important pour la mise en cache et la cohérence. C'est un problème que si l'alias est utilisé dans la clause WHERE sur une relation de collecte pour filtrer les objets connexes qui seront récupérées. Cela ne devrait pas être fait, mais il est parfois souhaitable, dans ce cas, la requête doit s'assurer qu'elle dispose le cache associé.

JOINTYPE

Par défaut join et fetch sont des jointures internes. Cela signifie que les résultats qui ne sont pas dans la relation seront filtrés à partir des résultats de la requête. Pour éviter cela, une jointure peut être définie comme une jointure externe à l'aide de OUTER JoinType comme argument à l'opération join ou fetch

ORDER

La requête de la clause orderby définit la façon dont les résultats de la requête seront classés. La clause ORDERBY est définie à l'aide de l'API orderBy sur CriteriaQuery. Seuls les objets Order peuvent être transmis à orderBy, et sont obtenus à partir de CriteriaBuilder utilisant l’API asc ou desc.

GROUPBY

La clause group by permet la synthèse des informations sur un ensemble d'objets. Group by est normalement utilisé en conjonction avec des fonctions d'agrégation. La clause group by est définie à l’utilisation d’API group by dans CriteriaQuery avec un objet d'expression valide.

HAVING

La clause Having permet d'avoir les résultats d'un group by pour être filtré. La clause Having est définie à l'utilisation de l'API CriteriaQuery avec n'importe quel prédicat de l’objet.

CRITERIAUPDATE (JPA 2.1)

CriteriaUpdate définit une requête de mise à jour de base de données. A tous les modèles de CriteriaUpdate des clauses d'un JPQL requête Mise à jour. Les éléments d'un CriteriaUpdate ne peuvent pas être utilisés dans d'autres CriteriaUpdate.

Un CriteriaUpdate est utilisé avec l'API EntityManager CreateQuery () pour créer une requête JPA. Pour des mises à jour régulières sur les objets, les objets doivent être lus par l'EntityManager dans une transaction d'une modification en Java, et que les modifications sont engagées.

CriteriaUpdate définit les clauses et les options suivantes:

CriteriaUpdate est utilisé avec l'API EntityManager CreateQuery () pour créer une requête JPA. La Mises à jour de Criteria doit être utilisé uniquements pour les mises à jour par lots. Pour des mises à jour régulières sur les objets, les objets doivent être lus par l'EntityManager dans une transaction d'une modification en Java, et ont commis des changements.

CriteriaUpdate définit les clauses et les options suivantes:

§ set (String, Object), set (Chemin, Object), set (Chemin, Expression) - Définit la clause set de la mise à jour.

§ where(Expression), where (prédicat ...) - Définit la clause where de la mise à jour. Par défaut tous les cas de la classe sont mises à jour.

Les expressions, les prédicats éléments sont définis en utilisant l'API CriteriaBuilder et l’expressions dérivées de la racine à partir d'éléments.

CRITERIADELETE

CriteriaDelete définit la requête delete dans une base de données. Un CriteriaDelete modélise des clauses d'un JPQL supprimer requête. Les éléments d’un CriteriaDelete ne peuvent pas être utilisés dans d'autres CriteriaDelete. un CriteriaDelete est utilisé avec l'API EntityManager CreateQuery () pour créer une requête JPA. CriteriaDelete doit être utilisé uniquement pour des suppressions de lots. Pour les suppressions régulières d'objets, les objets doivent être lus par l'EntityManager dans une transaction et supprimés par l'API remove (), et avoir les modifications validées.

CriteriaDelete définit les clauses et les options suivantes:

§ where (Expression), où (prédicat ...) - Définit clause where de suppression. Par défaut tous les cas de la classe sont supprimés.

Les expressions, les prédicats éléments sont définis en utilisant l'API CriteriaBuilder et expressions dérivées de la racine à partir des éléments from root.

WHERE

La clause where est normalement la partie principale de la requête, car elle définit les conditions (prédicats) qui filtrent ce qui est retourné. La clause where est définie en utilisant l’API where sur CriteriaQuery avec n’importe quelle prédicat objet. Un prédicat est obtenu en utilisant une opération de comparaison, ou une opération logique sur CriteriaBuilder. Le isNull, isNotNull, et in sont des opérations qui peuvent aussi être appelés dans l'expression. L’opération not peut également être appelée sur un prédicat.

SUBQUERY

Les sous-requêtes peuvent être utilisés dans L’API Criteria dans le select, where, order, group by, ou une clause having

Une sous requête est créée à partir d'un CriteriaQuery en utilisant l'opération subquery. La plupart des sous-requêtes restreint l’utilisation de sous-requête pour renvoyer un seul résultat et la valeur, à moins d’utilisée avec le CriteriaBuilder exists, all,any, ou l’opération some ou avec une opération in.

PARAMETERS

Les paramètres peuvent être définis à l'aide de l'API parameter sur CriteriaBuilder. JPA définit les paramètres nommés, et les paramètres positionnels. Pour les paramètres nommés le type de paramètre et le nom sont spécifiés. Pour les paramètres positionnels seule le type de paramètre est spécifié. Les paramètres positionnels début à partir de la position 1 pas 0.

FONCTIONS

Plusieurs fonctions de base de données sont prises en charge par l'API Criteria. Toutes les fonctions prises en charge sont définies sur CriteriaBuilder. Certaines fonctions ne peuvent pas être pris en charge par certaines bases de données, si elles ne sont pas conforme à SQL, et n'offrent aucune fonction équivalente.

OPERATIONS SPECIALES

L'API Criteria définit plusieurs opérations spéciales qui ne sont pas des fonctions de base de données, mais ont une signification particulière dans JPA. Certaines de ces opérations sont définies dans CriteriaBuilder et certains sont des interfaces d’expression spécifique.

METAMODEL

JPA définit un méta-modèle qui peut être utilisé lors de l'exécution pour demander des informations sur la cartographie ORM méta-données. Le méta-model comprend la liste des attributs mappés pour une classe, et leur cartographie types et cardinal. Le méta-model peut être utilisé avec L’API Criteria au lieu d'utiliser des chaînes pour référencer les attributs de la classe.

API définit un ensemble de classes qui sont généré par le fournisseur de l'API, ou IDE, qui donnent un compile au moment de l'accès à la méta-modèle. Cela permet au variables statiques d’ être utilisés dans l'API Criteria. cela peut réduire la fréquence des fautes de frappe, ou des requêtes non valides dans le code d'application, en capturant la requête au moment de la compilation, et non au cours des essais. Il n'a cependant rien ajouté à la complexité du processus de développement, le méta-modèle classe statique doit être généré, et faire partie du cycle de développement.

TUPLE QUERIES

Un Tuple définit un résultat de requête multi-sélection. Normalement, un tableau d'objet est retourné par l'API multi-sélection requêtes, mais un tableau d'objets n'est pas une structure de données très utile. Un tuple est une structure de map-like qui permet que les résultats soient récupérés par nom ou par index.