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…

[jmturc]

J'ai pas dit que LAZY et serialisation était liés,
je dis juste que une fois tes objets serialisés, ils sont "deconnectés" de la base, et donc le LAZY n'a, pour moi, aucun impact.



Merci quand même.

[JeitEmgie]

je vous redis, à mon avis et basé sur ce que vous avez dit jusqu'à présent :
utilisez LAZY correctement et vous n'aurez pas à vous posez de question d'inheritance juste pour une optimisation prématurée d'accès à un objet.

Quant à la doc, tu penses bien que le l'ai lu, mais s'il suffisait de lire la doc pour tout comprendre, il n'y aurais plus besoin de forum.

Je vous redemande : quelle stratégie d'inheritance avez-vous déclaré ?
Le fait que vous n'y répondez pas, sous-entend que vous ne comprenez pas l'impact que cela puisse avoir sur l'intérêt ou non d'utiliser l'inheritance uniquement pour une optimisation des accès…

( @Inheritance(strategy=InheritanceType.WHAT_IS_YOUR_CHOICE ?) )
vous devriez plutôt demander un conseil sur laquelle utiliser dans votre situation… au lieu d'introduire dans la conversion des considérations sur la couche présentation…

et concernant @Embeddable, la doc :

Annotation Type Embeddable

Defines a class whose instances are stored as an intrinsic part of an owning entity and share the identity of the entity.

[jmturc]

Pour la doc voici ce que j'avais trouvé : (extrais de http://www.theserverside.com/tt/arti...inginHibernate)


Remote Lazy Loading in Hibernate

May 2009
Discuss this article

Lazy loading in Hibernate means fetching and loading the data, only when it is needed, from a persistent storage like a database. Lazy loading improves the performance of data fetching and significantly reduces the memory footprint.

When Hibernate initializes the data object, actually it creates a reference (of the data) to the data object and doesn't load the data as such. Hibernate then intercepts the method calls to this reference and loads the actual data. In order to intercept and load the data, Hibernate requires the data object be associated with a Hibernate Session.

Problems might arise when these "lazy loaded" data objects (containing the reference) are transferred to other application layers, especially to remote client. These objects get serialized/de-serialized on their way to the remote client and there by detaching itself from the Hibernate Session. Accessing this detached reference will always lead to some exception.
What if these lazy loaded objects can still maintain their references even at the remote client layer (where there is no Hibernate Session) and still be able to lazy load data? This is quite possible and this concept of lazy loading data even from a remote client is called remote lazy loading.
................

Ce qui est en rouge est exactement ce que j'évoquai précédemment

[bassim]

Salut,
En définissant le type d'héritage (SingleTable, TableJoined) tu vas influencer la façon de créer et d'accéder à la BDD.
Si une seule table est utilisée pour User et User_Simple, tu ne pourras pas charger que les attributs qui te conviendront.

Je pense aussi que c'est un problème de conception, pourquoi ne pas créer une classe Detail_User qui sera un attribut de la classe User (avec un lazyLoding ça règlera ton problème).

[JeitEmgie]

jmturc,

1. "Lazy loading improves the performance of data fetching" : c'est bien la solution que je vous conseille d'explorer en lieu et place d' un design avec inheritance uniquement pour des questions d'optimisation (s'il a une autre raison liée au design OO de l'application c'est autre chose… et ça reste ouvert à discussion…)

2. l'idée invoquée dans l'article invoqué de contourner les problèmes d'exception dans le "remote client layer" liée au LAZY loading d'objets ne se pose QUE parce l'auteur croit que passer directement les objets du "repository layer" au "client layer" est la bonne façon de travailler… donc il résout un problème qui ne devrait même pas exister si le bon design de layers avait été choisi en amont…

3. vous demandez de l'aide mais quand on vous pose une question sur un point précis qui a une incidence fondamentale sur ce qui se passe question performance, vous ne prenez même pas la peine de répondre…
@Inheritance(strategy=InheritanceType.WHAT_IS_YOUR_CHOICE) SINGLE_TABLE, JOINED, TABLE_PER_CLASS ?