Charger partiellement une entité avec JPA

Il est intéressant, dans nombre de cas, de ne charger que partiellement une entité en JPA. Prennons l'exemple de JTentative, un agrégateur de flux RSS. Il est souhaitable de charger la liste des entrées appartenant à un flux, mais sans forcément charger l'intégralité de chaque entité (contenu et description sont des champs lourds et souvent inutilisés).

Plusieurs solutions existent pour charger partiellement une entité, de ne sélectionner que certains champs à charger depuis la base de données.

Première solution : FetchType.LAZY

La première solution consiste à définir certains champs de notre entité avec un attribut fetch à LAZY. Cela permet de spécifier que ces champs ne sont pas chargés lors du chargement de l'entité, mais uniquement lors du premier accès à ce champ.

L'annotation @Basic nous permet de spécifier ce lazy-loading.

Voici un exemple de code mettant en avant cette annotation. Le code de l'entité à été réduit pour plus de lisibilité :
@Entity
public class Entry implements Serializable {

    private static final long serialVersionUID = 1L;

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    private String title;

    private String author;

    @Lob
    @Basic(fetch=FetchType.LAZY)
    private String description;

    @Lob
    @Basic(fetch=FetchType.LAZY)
    private String content;

    /* Getters, Setters... */
}

Cette solution présente cependant un inconvénient majeur : si elle fonctionne correctement lorsque l'on charge une entité via l'EntityManager, elle est complètement inefficace lors de la sélection de données via une requête JPA-QL.

Seconde solution : Sélectionner uniquement les champs dont on a besoin

Une seconde solution peut-être mise en place dans une requête JPA-QL. Cependant, elle ne fonctionnera paslors de la sélection lors d'un appel à la méthode find() de l'EntityManager.

Cette solution est basée sur un opérateur méconnu du langage JPA-QL, new. L'opérateur new permet d'intancier des objets au sein d'une requête JPA-QL. Il s'agit donc d'instancier un objet, en fournissant au constructeur uniquement les champs que nous souhaitons récupérer.

Voici un autre exemple, le code de l'entité a là aussi été réduit :
@Entity
@NamedQuery(name="Entry.findAll", query="SELECT new Entry(e.id, e.title, e.author) FROM Entry AS e")
public class Entry implements Serializable {

    private static final long serialVersionUID = 1L;

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    private String title;

    private String author;

    @Lob
    @Basic(fetch=FetchType.LAZY)
    private String description;

    @Lob
    @Basic(fetch=FetchType.LAZY)
    private String content;

    public Entry() {
    }

    public Entry(Long id, String title, String author) {
        this.id = id;
        this.title = title;
        this.author = author;
    }

    /* Getters, Setters... */
}

Quelques précisions cependant :
  • Il faut préciser la classe complète de l'entité dans la requête, incluant le nom du package
  • Le constructeur que l'on souhaite invoquer doit exister
  • Prennez garde avec vos entités chargées de cette manière : certaines propriétés sont absentes, une mise à jour dans la base de données avec une entité chargée partiellement risque d'effacer certaines valeurs


Le code complet de l'entité utilisée pour cette exemple est disponible sur le dépôt SVN de JTentative.

Permalink  |  Commentaires (2)

Aperiquiz #4 : Integer equals Integer

Soit le code suivant :


Quel est la valeur de c ?
  • true
  • false
  • Erreur de compilation
  • Une exception est levée lors de l'exécution
Réponse : (cliquez pour afficher)

Permalink  |  Commentaires (5)

Types primitifs : pièges courants

It's a trap

Je viens de tomber dans la soirée sur deux pièges, non triviaux, mais facile à éviter pour peu de les connaître...

27/10 != 2.7

Le premier bout de code ressemblait à celui-ci :
public class Main {

    public static void main(String... args) {
        float price = 27/10;
        System.out.println("Price: " + price);
    }

}

Alors qu'il est facile de penser que le code suivant va afficher "Price: 2.70" lors de l'exécution, la réalité est tout autre. Effectivement, le résultat une fois ce code compilé / exécuté est "Price: 2.00".

Le piège est le suivant :
  • 27 est, en Java, un entier
  • 10 est, toujours en Java, un entier
  • L'opération 27/10 est la division de deux entiers. Pour la JVM, le résultat est donc un entier. Donc 2.
  • La valeur 2 est assignée à une variagle de type float, la valeur 2 est transformée en 2.00
  • La valeur 2.00 est affichée dans la console.

Il est facile de contourner ce problème : transformer notre division d'entier en division de nombre flottants :
public class Main {

    public static void main(String... args) {
        float price = 27.0/10.0;
        System.out.println("Price: " + price);
    }

}

Dans ce bloc de code, 27.0 et 10.0 sont des nombres à virgule flottante. La division des deux donne une nombre à virgule flottante, donc 2.7. Et le résultat est donc celui attendu.

return (int) 2.7 - 2.4;

Le second bloc de code piégé consistait à comparer deux entiers :
public class FloatComparator implements ComparatoréFloat> {

    public int compare(Float f1, Float f2) {
        return (int) (f2 - f1);
    }

}

A première vue, ce code semble lui aussi entièrement correct. Le raisonnement suivi est celui-ci :
  • Si je renvoie le résultat de f2 - f1, mon objet triera des nombres par ordre croissant
  • La méthode compare doit renvoyer un entier
  • Je caste le résultat de ma soustraction (un float) en int.

Ce code fonctionne presque tout le temps. Le problème tiens dans le presque... Pour comprendre où est le problème, rien ne vaut une simulation :
  • Je souhaite comparer 2.7 et 2.8
  • 2.8 - 2.7 renvoie 0.1, un nombre positif, donc je respecte le contrat de la méthode compare
  • 0.1 est casté en int, le résultat est 0 alors que f2 est suppérieur a f1, je ne respecte plus le contrat de ma méthode

L'erreur se trouve dans le cast. Il faut donc effectuer un changement dans notre méthode pour renvoyer un nombre positif dans tous les cas où f2 est suppérieur à f1. Par exemple :
public class FloatComparator implements ComparatoréFloat> {

    public int compare(Float f1, Float f2) {
        if (f2 > f1) {
            return 1;
        }
        if (f1 < f2) {
            return -1;
        }
        return 0;
    }

}
Le contrat de Comparator est maintenant respecté.

Permalink  |  Commentaires (0)

Aperiquiz #3 : Paramètres de méthodes

Quel est le nombre maximum de paramètres pour une méthode ?

  • 127
  • 255
  • 256
  • Il n'y a pas de limites
  • Cela dépends du compilateur

Réponse : (cliquez pour afficher)

Permalink  |  Commentaires (1)

RichFaces : Filtrer et trier une DataTable

Après avoir installé RichFaces, je me suis lancé dans la rédaction d'une page d'exemple, histoire d'apprendre le fonctionnement de cette librairie qui semble bien intéressante.

Le but de cette page d'exemple est de mettre en place une DataTable, avec fonctionnalités de tri et de filtres. Toutes ces fonctionnalités utiliseront de l'Ajax, et il ne sera donc pas nécéssaire de recharger la page afin de voir les changements.

Les contacts contenus dans notre DataTable devront être triés par nom de famille par défaut. Il sera également possible pour l'utilisateur de changer l'ordre de tri (croissant, décroissant), ainsi que la propriété servant à effectuer ce tri (prénom, nom, ou adresse mail).

Enfin, pour le filtre, nous aurons un champ de texte qui limitera la liste aux contacts :
  • Dont le nom commence par la requête
  • Dont le prénom commence par la requête
  • Dont l'adresse mail contient la requête

Mise en place d'une Rich DataTable

Afin de commencer notre page d'exemple, nous allons créer une classe Contact, qui aura pour vocation de contenir les données. Cette classe est un JavaBean, et possède donc les caractérisques suivantes :
  • Les propriétés doivent être privées
  • Chaque propriété doit avoir des accésseurs (getters et setters) publics
  • La classe doit avoir un constructeur par défaut
  • La classe doit implémenter Serializable


Nous allons donc créer notre classe Contact avec les propriétés firstName, lastName et mailAddress :

La seconde étape sera de créer un managed bean JSF, qui nous renvera une liste de contacts d'exemple :

Et enfin, dernière étape, nous allons créer notre Rich DataTable, basique pour l'instant, capable d'afficher ces données :

Nous avons dans l'exemple de code précédent créé une Rich DataTable. Le code ressemble à celui d'une DataTable classique, la seule différence étant l'utilisation de la taglib RichFaces au lieu de la taglib standard.

Rajout des fonctionnalités de tri

L'ajout du tri dans une Rich DataTable est très facile. La balise <rich:column /> possède un attribut sortBy, qui permet de spécifier la propriété qui sera utilisée pour trier la colonne concernée.

Notre code précédent ressemble donc désormais à ceci :
L'exécution de ce code nous montre que sur chaque colonne, RichFaces a rajouté des boutons permettant à l'utilisateur de choisir quelle colonne sera utilisée pour trier les données, et de choisir l'ordre de tri.

Il est également possible de donner un ordre de tri par défaut à notre DataTable. Pour celà, nous allons utiliser l'attribut sortOrder de notre balise <rich:column /> :
Ainsi, au lancement de la page, les contacts seront triés par ordre alphabétique en fonction de leur nom de famille. Il sera également possible pour l'utilisateur de changer la propriété servant à faire le tri (et de choisir le prénom, ou l'adresse mail). L'utilisateur aura également la possibilité de changer l'ordre de tri (croissant, décroissant).

Filtrer les données

Le filtrage des données à l'intérieur d'une DataTable passe par plusieurs étapes :
  • Il faut commencer par créer un champ de texte, permettant à l'utilisateur de rentrer la requête sur laquelle nous allons nous baser pour filtrer les entrées
  • Il faudra ensuite créer une méthode permettant de filter chacune de nos entrées. Cette méthode prends en paramètre l'objet à filter, et renvoie un booléen indiquant si l'objet doit être affiché
  • Enfin, il faudra que notre DataTable soit mise à jour à chaque modification de la requête

La première étape est donc de créer notre champ de texte. Il s'agit d'un simple champ de texte JSF (<h:inputText />) que nous allons lier à une propriété d'un managed bean : Puis le code JSP correspondant :
Seconde étape, toujours dans notre managed bean, nous allons créer une méthode filtrant les objets de type Contact en fonction de la requête qui nous est envoyée par le champ de saisie. Dans l'exemple ci dessous, la méthode doFilter prends en paramètre l'objet que nous allons devoir filtrer (dans notre cas, on objet de type Contact), et dois renvoyer true si le contact doit être affiché, false sinon : Nous allons également dire à notre DataTable d'utiliser cette méthode afin de filtrer les entrées à afficher :
Enfin, dernière étape, nous allons préciser à RichFaces que notre champ de texte doit automatiquement rafraîchir, en Ajax, notre DataTable afin que les données soient de nouveau filtrées, avec la nouvelle requête : La balise <a4j:support /> permet, entre autres, de mettre rafraîchir un composant. Elle prends 3 paramètres :
  • event : l'évènement JavaScript qui devra déclencher le rafraîchissement
  • reRender : le composant à rafraîchir
  • requestDelay : permet de spécifier un délai entre la requête et le refraîchissement du composant

A chaque fois que la valeur du champ de texte est modifiée, la nouvelle valeur est envoyé dans notre managed bean, et notre DataTable est raffraîchie. Ainsi, le tableau va de nouveau être filtré, et notre méthode va permettre d'éliminer certains résultats de notre tableau.


Nous avons donc vu un premier exemple de fonctionnalité Ajax qu'il est possible de réaliser grâce à RichFaces. Une DataTable avec fonctionnalités de tri et de filtre, qui se rafraîchit sans recharger la page.

Les sources du projet NetBeans de cet article sont disponnibles ici.

Permalink  |  Commentaires (2)