Association seulement avec la clé, pas avec l'objet ?

Bonjour à tous,

Voilà, j'ai un problème très simple, mais pourtant très difficile à résoudre :

supposons qu'on a une classe A, une classe B, et une association de A vers B

En bref, le modèle database est le suivant :

-------------
table A :
-------------
int x
int y
long B_id
-------------
alter table A add constraint FK0 (B_id) references table B

-------------
table B :
-------------
int z
-------------

Mon problème en fait se situe au niveau du modèle objet :
- en fait, pour tout un tas de raisons spécifiques, j'aimerai avoir des objets qui ne contiennent que des getters vers l'ID de B, et pas vers B lui-même.

Typiquement, voici le modèle objet que j'aimerai avoir :

class A {
int x;
int y;
long B_id;
}

Et voici le modèle classique hibernate, que je ne veux pas avoir :

class A {
int x;
int y;
B z;
}

Pour être plus précise, ma class A représente une entité qui contient plusieurs centaines de valeurs, chaque valeur étant un B. L'idée de gérer les B dans une table plutôt que comme des attributs est justemenet de bénéficier du système de clé étrangères, qui ferait que lorsqu'on modifie une valeur de B, via les clés cette valeur sera modifiée pour tous les A.

Le problème étant que je n'ai pas envie, pour des raisons de performance, à chaque fois que je load un A, de loader en même temps les centaines d'objets B qui lui sont associés. Et donc je souhaiterai n'avoir que leurs ids.

Si quelqu'un a une idée sur comment on peut réaliser ça ?

Merci beaucoup par avance,

A+,
Stève

Citation:

---

Le problème étant que je n'ai pas envie, pour des raisons de performance, à chaque fois que je load un A, de loader en même temps les centaines d'objets B qui lui sont associés. Et donc je souhaiterai n'avoir que leurs ids.

---

Si tu as ce modèle:

Citation:

---

class A {
int x;
int y;
B z;
}

---

Quand tu chargeras un élément A, tu ne chargeras que l'élément B qui lui est associé.

A moins que tu ne voulais écrire :

Code:

---

1 2 3 4 5

class A { int x; int y; List listeDeB; }

---

Mais même dans ce cas, le "lazy loading" te permet de charger les collections à la demande.
Je ne vois donc pas l'intérêt de faire comme tu le proposes.

En fait, c'est pour ça que j'ai précisé que c'était lié à tout un tas de raisons spécifiques, qui sont spécifiques à mon projet actuel, et trop longues à décrire.

Disons, pour faire simple, que j'ai 2 choses :
1) pour chaque objet A, on a une structure de ce type :
A{
B var1
B var2
.
...
.
B var300
}

2) à côté de ça, on dispose déjà, du côté client IHM de la liste de tous les B

Donc ce que je souhaiterai, c'est que lorsque l'ihm cliente load un objet A (pour des besoins encore une fois spécifiques, il faut qu'elle le load en une fois), elle n'ait pas à loader l'ensemble des 300 objets B.
Mais qu'elle ne load que leur id, comme si c'étaient des variables long.

L'intérêt c'est que le load sera léger.
Et la réassociation des A et des B se fera au niveau IHM, en utilisant les ids.



Une autre façon de le formuler, peut-être beaucoup plus claire, est la suivante :
j'aimerai avoir un objet du type :
A {
long id_B_1
long id_B_2
...
long id_B_300
}
et avoir dans la base les contraintes suivantes :
alter table A add constraint FK0 (id_B_1) references table B
...
alter table A add constraint FK0 (id_B_300) references table B

Voilà,
donc si quelqu'un a une idée,

A+,
Stève

Je n'ai pas d'idée.
La seule chose que je vois serait de faire du lazy loading sur tous les attributs de B y compris les propriétés simples puisque tu ne veux rien charger.
Je ne connais pas la complexité de ton objet B, mais 300 objets, ce n'est pas la mort.

C'est effectivement la solution vers laquelle je m'oriente : du lazy-loading.
le problème, c'est qu'une fois sur le client distant, il me faut l'id de chaque B pour pouvoir recrér l'association, ce que je n'aurai pas avec le lazy-loading.

J'envisage donc ces 2 solutions :
1) soit je "duplique" l'info, en stockant dans A à la fois B et l'id de B, un truc du genre
class A {
long id_var_B_1
B var_B_1

public void setB_1(B b) {
this.var_B_1 = b;
this.id_var_B_1 = b.getId();
}

}

comme ça je garde la contrainte de clé étrangère en base, et je peux faire du lazy-loading pour charger A puisque j'aurai les id pour recréer les associations

mais ce n'est pas super propre de dupliquer l'info comme ça.

2) soit je ne stocke que l'id de B à l'intérieur de A, un truc du genre :
public A {
long id_var_B_1

public void setB_1(B b) {
this.id_var_B_1 = b.getId();
}

}

c'est plus propre mais je perds la contrainte de clé étrangère.


Donc voilà, chacune des 2 solutions a un inconvénient, donc je les utiliserai si je ne trouve rien d'autre.

Sinon, 300 objets à loader ce n'est pas grand chose, ça dépend : dans mon cas, chaque utilisateur loadera plusieurs centaines de B (donc plusieurs dizaine de milliers d'objets A). Et en sachant qu'il y a quelques centaines d'utilisateurs......

A+,
Stève

Si je ne dis pas de connerie, l'id des objets est tjrs disponible même en cas de lazy loading. Ce qui parait logique sinon il n'y aurait pas moyen de récupérer les autres infos.

Tout dépend ce que tu fais de tes objets. Si tu les laisses en session, effectivement, ça peut faire beaucoup de mémoire d'utilisée.
Sinon, si c'est juste pour de l'affichage dans une jsp, la mémoire est libérée au moment du rendu dans la jsp, donc ça ne devrait pas poser de problèmes.

Merci pour ce tuyau : je ne savais pas.

Et effectivement ça semble être la solution : j'ai déclaré tous mes B comme étant en lazy="proxy", et lorsque je charge un A hibernate ne charge pas l'intégralité des B, tout en me permettant d'appeller A.getB().getId();

Ceci étant, il charge quand même une petite partie des objets B, donc je vais faire des tests de perfo pour voir ce que ça donne.

A+,
Stève