Discussion :

[jmturc]

bonjour,

simplifions le problème au maximum:
J'ai une table USER contenant 5 champs.
J'ai donc un object java USER contenant les 5 attributs.

Pour des questions de performance, je voudrais un objet SIMPLE_USER qui contient que 2 attributs de la table USER. (Cela me permet d'avoir rapidement une liste de SIMPLE_USER sans charger tout les attributs de USER).

Par contre je voudrais que la classe USER herite de SIMPLE_USER (histoire de reutiliser les attributs deja mappés).
J'utiliserai bien @MappedSuperclass, mais du coup, je ne peux plus faire de query sur SIMPLE_USER.

En gros, quand j'enregistre un user c'est forcement du type USER, et quand je lis, ca peut être un USER ou un SIMPLE_USER selon mes besoins.

Une idée ?
Merci

[JeitEmgie]

Pour des questions de performance, je voudrais un objet SIMPLE_USER qui contient que 2 attributs de la table USER. (Cela me permet d'avoir rapidement une liste de SIMPLE_USER sans charger tout les attributs de USER).

à moins que les 3 attributs que vous ne chargez pas ne soient de gigantesques BLOB (auxquel cas un chargement LAZY serait plus intelligent) depuis quand ne pas charger 3 attributs va-t-il apporter une quelconque gain de performance notablement significatif sur les plateformes (hardware et software) modernes ?

de toute façon, au vu de l'implémentation par les ORM, vouloir utiliser l'inhéritance pour de l'optimisation "vitesse" est contre-productif… quelle que soit la stratégie d'inhéritance choisie…

[jmturc]

heu, j'ai bien précisé que l' exemple est une simplification.
Les 5 attributs ne sont qu'un exemple très très simplifié.
.
En fait, un USER contient 20 attributs environ et des sous classes ( PROFIL, OFFICE,.....) alors que SIMPLE_USER contient que quelques attributs simples.

Dans mon ecran de management de user, je dois afficher la liste des users ,
Je me vois mal allez loader la liste de tout les USER (attributs + PROFIL + OFFICE +......), je preferais loader la liste des SIMPLE_USER.

Par expérience, je sais que la méthode "List<User> getListUser()" sera lente,
alors quez List<SimpleUser> getListSimpleUser()" sera beaucoup plus rapide puisque je ne fais pas de jointure sur PROFIL OFFICE,............

Donc si ce n'est pas productif d' utiliser l'inhéritance pour de l'optimisation ,
alors comment faire ?

Merci

[JeitEmgie]

fetch = FetchType.LAZY

pour les relations OneToMany qui ne sont pas indispensables dès l'utilisation de l'objet "owner"…

et relisez la doc concernant les différents méthodes de stockage en cas d'inhéritance pour bien comprendre ce qui se passe dans chacun des cas…
au niveau des fetch, des insert et des locks…

[jmturc]

ok,
mais suppose que cette liste d'objet est affiché dans flex (via blazeds),
cela veut donc dire que tout les objects crées en JPA sont deconnectés de la base, puis sérialisés sur le reseau pour ensuite être affichés dans le browser.
Dans ce cas, sauf erreur de ma part, le LAZY ne sert a rien , non ?

Que ce soit flex ou un client lourd type swing , c'est le même problème.
Comment faire pour recuperer une liste d'objet allégés (SIMPLE_USER) sans lire les objets lourds (USER) tout en gardant l'heritage object, et sans pour autant que JPA ne gere cet heritage cote base (avec le fameux DTYPE).

LA seule solution , pour le moment, est de ne pas faire d'heritage entre SIMPLE_USER et USER, (ca fonctionne bien), mais cela signifie une duplication des attributs, dommage !

J'ai essayé avec l'encapsulation (@Embeddable/@Embedded) : un USER contient un SIMPLE_USER,
mais la, c'est la primary key qui pose probleme,
pas reussi a rendre @embedable la primary key

[JeitEmgie]

LAZY permet de contrôler le chargement des objets lors de l'accès au SGBD et n'a rien à voir avec la sérialisation pour la présentation

l'INHERITANCE côté OO peut se concrétiser de manières très différentes côté SGBD suivant la stratégie choisie

et évidemment qu'on ne peut mettre l'@Id dans les @Embeddable puisque par définition celui-ci PARTAGE son identité avec celui qui l'incorpore via @Embedded…



un seul conseil : lire la doc…