Re: [HS] Introduction d'une solution ORM

Si je résume, ce projet est mis à jour uniquement pour des raisons de perfs à venir.
C'est une bonne raison.
Il faut donc étudier les goulets d'étranglements et agir dessus, mais uniquement sus ces goulets d'étranglement.

Ensuite, il y a la maintenance et les modif du schéma, c'est une bonne raison pour passer à un ORM, mais en effet, attention aux autres aspects de cette migration impose : clés primaires non techniques à migrer, ...


Sinon, il y a une raison solide pour utiliser OpenJPA et non pas Hibernate : 
* apparement toujours pas d'annotation pour spécifier des valeurs par défaut !
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34014#action_34014

* les fetch plan.
http://webspherepersistence.blogspot.com/2009/02/dynamic-fetch-planning.html

En gros, les lien de propagation des actions sont défini statiquement via CASCADING et les liens pour retrouver l'info sont codé statiquement via EAGER, mais tout est statique dans Hibernate.
Si tu veux du dynamique, tu met en LAZY et tu fait plein de get/set avec du lazy loading : c'est mal !

J'espère que cela ve déclencher une bonne discussion sur ce point :-)

Voici quelques éléments que j'avais écris il y a un moment pour l'expliquer :

The need is simple : get trees of partially valuated business object instances from the "big graph" of possible linked business classes.
That come from old SQL good practice :
1. only get back from DB what you need.
2. the other thing is to try to make as few trip to the DB as possible. One request is better than several.
DB will optimized if the request look like complex.
In other words, let the DB optimize for you, as much as possible.

So, I'm in Java, I want instances of my business classes but with only attributes I need (rule 1).
That attributes that had to be taken or left from the DB can be @Basic one or any other relational one like @ManyToOne, @OneToOne, ...
I also want to express that in one request ideally (point 2).
I let the Java framework optimize for me and send as few SQL request as possible.

Basically, there is 2 "filters" to distinguish :
* vertical one that can filter several "lines" from the million in the table : this is the WHERE clause
* horizontal one that can bring back only certain column : this is the SELECT clause
both are usefull.

Vertical one are well taken into account by all the frameworks I had to use.

Horizontal one had been poorly taken into account by other frameworks I had to use.
I can get back with some instances (vertical filter) but with all attributes (bad horizontal filter).
Or I can have both working but the result is an array of hash tables and I need instances of my business classes.
This is really bad since that hash map's keys are not the attribute (field) name but the position in the SELECT clause !
Meta information is just lost in translation and nobody care :-)

Some framework are able to handle poorly (better than not handling at all) horizontal filtering via eager or lazy loading but this only concern relational attributes excluding @Basic one and also, most of the time this can't be set dynamicaly and you have to provide as a developper specific constructor of your business class.
All that horizontal filtaring has to be set statically via annotation or more painfully via XML but not dynamically.
At the end, it is a lot of work for the developper for not having real horizontal filter.

As a conclusion, and as far as I know, OpenJPA was the only one able to give me back some (efficient vertical filter) instances of my business classes partially valuated depending on my needs (efficient horizontal filter) both filters can be specified entirely dynamically if I want but it is also statically via annotation.
This had been possible with only one request.


On 6 juin 2011, at 11:25, Eric Le Goff wrote:

> Bonjour la liste,
> 
> Je suis un peu hors sujet, mais le lien avec java est que ma question porte sur les solutions ORM.
> Le contexte est une reprise de  projet struts (v1.2.4 !) avec visiblement utilisation de patterns DAO/DTO 
> Pour info la BDD est Oracle mais je ne pense pas que ca puisse avori une influence sur vos reponses
> 
> Ce projet est très stable, en production depuis plus de 7 ans (d'ou la version obsolète de struts), mais il s'agit de lui donner un petit coup de dépoussiérage et surtout se donner les moyens pour faire face à un doublement potentiel du nombre d'utilisateurs dans les prochains mois. Il va s'agir aussi de faciliter la vie future ou le modèle des données risque d’évoluer a moyen terme.
> 
> Voici donc mes questions :
> 
> * Est-ce qu'avec ce contexte vous preconiseriez une solution ORM ? Si oui laquelle ? (Hibernate ? OpenJPA ? Autre ?)
> NB : pour l'instant mes recherches sur le sujet donnent des resultats mitigies : [1]
> 
> * Sachant  la modélisation des tables n'est pas en 3eme forme normale, est ce qu'une action sur le modele physique des donnees est un pre-requis avant d'envisqger une solution ORM ?
> 
> * Enfin d'une maniere tres generale, preferez vous la prudence ("if it works, don't fix it") ou préférez vous éviter les situation ou les frameworks utilises risquent l’obsolescence ?
> 
> Merci de vos retours d'experience.
> 
> Eric
> 
> [1] : http://openjpa.208410.n2.nabble.com/Why-would-I-choose-OpenJPA-over-Hibernate-td210139.html
> 
> --
> Eric Le Goff
> twitter: @elegoff
> linkedin: http://www.linkedin.com/in/elegoff
> 
>