Catégorie: Persistance

Bonjour à tous,

Soirée EclipseLink le 19 Janvier 2012 avec Shaun Smith

A propos de Shaun Smith :
Shaun Smith travaille à Oracle sur EclipseLink. Il viendra nous faire le plaisir de nous présenter tout ça.

A propos de l'intervention
Dès qu´on parle d´ORM ou de persistence, on pense brièvement à JPA puis on parle d´Hibernate, mais on oublie souvent que l´implémentation de référence de JPA c´est EclipseLink. Eh bien ce soir nous allons rectifier le tir, et vous présenter non seulement EclipseLink, mais encore mieux nous allons voir des aspects très pratiques de son utilisation.

En premier nous allons ainsi voir comment utiliser EclipseLink pour réaliser des applications Web RESTful, puis nous allons découvrir comment résoudre les problèmes de multitenancy

Nous nous réunirons à :
Technopôle Marseille Provence
Château Gombert
Les Baronnies, Bâtiment B, RDC
Rue Paul Langevin
13013 MARSEILLE

(le bâtiment rouge que l'on aperçoit ici)

N'hésitez donc pas à venir nombreux le Jeudi 19 Janvier 2012 à 19h30

Comment puis-je ne rien rater du MarsJUG ?
Vous pouvez suivre son twitter

Merci de vous inscrire à cette conférence et à la mailing list

Pourquoi venir au MarsJUG ?
Comme tous les JUGs le MarsJug permet de rester à la pointe de ce qui se fait en Java en participant à des conférences et rencontrer des speakers reconnus dans le monde.
Vous pouvez venir par curiosité pour découvrir les JUGs, par amour des JUGs parce que vous êtes habitués, pour vous tenir au courant de se qui se fait de nouveau ou alors pour boire un coup avec nous après le JUG

A quelle fréquence le JUG se réunira ?
Un moyenne tous les mois et demi

à bientôt,
Alain Defrance.

Toujours dans le cadre du projet (dont la structure a été expliquée au post précédent ici.

Nous sommes confrontés à un autre problème :
si les classes POCO sont internal... le problème du post précédent est le même : non récupération des sous objets...

Bon à savoir...

Et hop, un jour de perdu sur ce projet. La raison : le trinome EF - POCO - et un constructeur dans un objet POCO.

Pour resituer le contexte, nous réalisons une application qui, entre autre, parse des fichier, et normalise les données contenues.

Ces données sont manipulée par un ORM (object-relational mapping) : Entity Framework 4, et ce en mode POCO (Plain Old CLR Object).
Ce qui signifie, que nous avons totalement la main sur le code des classes manipulées, et Entity Framework est responsable de la gestion des instances de ces classes, avec le moteur de Bdd.
Enfin, pour que le contexte soit complet, j'ajoute que la gestion de l'état des instances est réalisé par la mise en virtual des propriétés des objets (Du coup, EF crée un proxy sur mon objet pour gérer son état).

Ces classes (internal à l'assembly) implémentent des interfaces (publiques), et sont instanciées par une fabrique.
Les assemblies consommateurs n'ont donc ni conscience de l'implémentation réelle, ni de la façon dont sont instanciées les classes. (bref un couplage faible).

Le problème : J'ai une classe Voiture qui contient une propriété Moteur. Ce dernier contient les propriétés Batterie , Compresseur de Climatisation. (tous ces types sont des types références, donc des classes)

Pour récapituler :

public class Voiture
{
  public Moteur MonMoteur { get; set; }
}

public class Moteur
{
  public Moteur()
  {
    this.MonCompresseurClim = new CompresseurClim();
    this.MaBatterie = new Batterie();
  }

  public CompresseurClim MonCompresseurClim { get; set; }
  public Batterie MaBatterie { get; set; }
}

public class CompresseurClim
{
   // …        
}

public class Batterie
{
  //…        
}

Lors de l'instanciation de la voiture, la valeur du moteur est instanciée par le constructeyr (pour éviter les null, les consommateur de ces classes les manipulent à travers leurs interfaces qui ne permettent pas les setter.), lors de l'instanciation du dit moteur, les valeurs de Batterie, et CompresseurClim sont instanciées.
Ceci est réalisé dans les constructeurs respectifs (classes partielles), bien entendu.

Le problème : lors de la récupération de la voiture depuis la base de données (via EF),
le moteur est bien récupéré en Lazy load, mais
la batterie et le compresseur ne correspondent pas à la valeur en base de données.
Pire : EF est incapable de récupérer le valeur correcte du moteur !
En lieu et place, les propriétés sont instanciés avec les objets par défaut.

Pour diagnostiquer j'ai :
- Mis en place le SQL Server Profiler (pour visualiser le sql d'EF,
- remonté le modèle EF dans un autre projet, en remontant par passe successive le T4 POCO, puis les classes partielles, les interfaces,

je me suis rendu compte que le problème apparaissait dans cette appli de test, juste après l'insertion du code des classes partielles.

Puis, en supprimant le contenu du constructeur du moteur (qui initialise la batterie et le compresseur de clim avec les valeurs par défaut), EF ne plante plus et récupère correctement les valeurs...

J'en déduis que, lors de la création du proxy EF sur mon objet, il doit analyser le constructeur, repiquer mon code et l'exécuter après ses requêtes en db... du coup, mes valeurs sont toujours à leur état par défaut !

Attention donc, aux constructeurs dans des classes EF - mode POCO !!!

PS : si quelqu'un sait ce qui se passe précisément...
Re-PS : les classes ne correspondent pas à la réalité (si si si )

Beaucoup de jeunes développeurs n'utilisent jamais que le VARCHAR comme type de données pour les littéraux. Mais ce type possède des inconvénients masqués. Nous allons comparer les deux afin que votre choix soit éclairé !

» Lire la suite!

Mais que ce fût dur !

J'avais déjà fait une vidéo sur la création d'un pool de connexion MySQL sur Glassfish. Malheureusement, lors de la pratique en test réel avec une application web et des alpha-testeurs, plus rien ne fonctionnait au bout de quelques heures : "Impossible to resize Pool" x 500 dans mes logs.

» Lire la suite!

En ce moment, je réécris totalement le code serveur du site Edupassion.com. Et après avoir découvert JPA il y a seulement quelques semaines, je suis maintenant sûr que la plupart des accès à la base de données d'Edupassion seront fait en JPA : plus simple à maintenir.

Cependant certaines requêtes seront très fréquemment utilisées par les utilisateurs : l'accès aux tokens d'authentification, et l'accès aux notes pour les profs et élèves. Il me parait donc logique de faire du JDBC pour optimiser ces deux-trois cas d'utilisation. Mais JDBC est-il vraiment plus rapide ? JPA vs JDBC : voici ce que j'ai trouvé sur java.net :

» Lire la suite!

JPA (Java Persistence API) sera sans doute le dernier de mes joujoux technologiques pour bâtir l'architecture de la plateforme pédagogique Edupassion.com.

Tout cela fait beaucoup de technologies pour un seul homme. Ext-JS risque d'être le point faible... et le plus visible.

» Lire la suite!

Ma dernière lecture, laborieuse tant il est difficile de trouver du temps de libre, aborde le framework de mapping objet/relationnel Hibernate. Curieux hasard car c'est ce dernier que j'utilise quotidiennement depuis quelques mois ;-). Je serais honnête, bien qu'en général j'aime les publications O'Reilly : ce livre ne m'a pas aidé.

• La critique de "Harnessing Hibernate" (O'Reilly)

L'équipe d'EclipseLink vient d'annoncer la sortie de la version finale d'EclipseLink, un framework de persistance pour Java utilisable avec des bases de données relationelles, non realtionelles ou fichiers XML, et exposant plusieurs APIs (JPA, JAXB, etc.)

» Lire la suite!

Suite à ce billet que j'ai rédigé pour montrer comment mettre en place JPA/Hibernate en mode managé avec Spring, on m'a à maintes reprises demandé de fournir une application exemple pour montrer en pratique ces concepts.

» Lire la suite!

L'Expert Group de la JSR 317 vient enfin de sortir un Early Draft pour le futur JPA 2.0.

Voici quelques unes des nouveautés que JPA 2.0 apporterait:

» Lire la suite!

Bonjour,
L'utilisation de JPA dans un environnement non managé peut se revéler délicate et problématique (la fameuse LazyInitException en est un exemple).

Ca vient surtout de la gestion de la session de persistence, qui dans le mode non-managé doit être gérée à la main par le développeur, or la méthode la plus simple qui consiste à ouvrir une session de persistence chaque fois qu'on en a besoin est pour lemoins inefficace, lourde, et ne marche pas avec le chargement lazy, ne permet pas une gestion correcte des transactions (étalées sur plusieurs actions), etc.

C'est pour cela qu'il vaut mieux (faut) utiliser un conteneur pour la gestion de la session de persistence (JPA, Hibernate, etc.) comme par exemple Spring.

Je vais présenter rapidement dans ce billet les étapes à suivre pour configurer Spring 2.5 et JPA dans le cadre d'une application Web (ne nécessite pas un serveur d'application, marche sur Tomcat et Jetty).

» Lire la suite!