Discussion :

[minimarch76]

Bonjour à tous,

j'ai deux classes AntivirusFirewall et AntivirusFirewallInstallation, qui sont liées tous les deux par une relation one-to-one, telle que définit de la façon suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
<union-subclass name="AntivirusFirewall" table="av_fw">
 
	<property column="numdossier" name="numDossier" not-null="true" type="string" />
 
	<one-to-one cascade="all" fetch="join" class="AntivirusFirewallInstallation" lazy="false" name="Installation" />
 
</union-subclass>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
<class name="AntivirusFirewallInstallation" table="av_fw_installation">
 
	<id column="cle" name="Cle" type="string">
		<generator class="foreign">
			<param name="property">AntivirusFireWall</param>
		</generator>
	</id>
 
	<property column="datecreat" name="Date" type="date" />
 
	<one-to-one cascade="all" fetch="join" class="AntivirusFirewall" lazy="false" name="AntivirusFirewall" />
</class>

Le problème est qu'Hibernate me génère la requête suivante (que j'ai simplifié) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
    select
        this_.iduser as iduser109_2_,
        this_.numdossier as referer109_2_,
        avf2_.cle_finale as cle1_116_0_,
        avf2_.datecreat as datecreat116_0_,
        avf3_.iduser as iduser109_1_,
        avf3_.numdossier as referer109_1_,
    from
        av_fw this_ 
    left outer join
        av_fw_installation avf2_ 
            on this_.iduser=avf2_.cle_finale 
    left outer join
        av_fw avf3_ 
            on avf2_.cle_finale=avf3_.iduser 
    where
        this_.numdossier=?

Comme vous pouvez le constater, pour un accès à seulement deux tables, Hibernate génère un select sur la table AntivirusFirewall, un outer join sur la table AntivirusFirewallInstallation pour récupérer l'installation associée, et de nouveau un outer join sur la table AntivirusFirewall pour récupérer l'antivirus associée à l'installation. Je pense que le dernier outer join est inutile puisque les informations qu'il récupère sont exactement les mêmes que pour le select original.

Est-ce qu'il y a moyen de changer mon mapping pour éviter le dernier outer join, consommateur inutile de ressources ?

Merci par avance pour vos réponses,
MiniMarch

[fr1man]

Et en faisant avec un many to one d'un coté (avec unique="true") et un one to one de l'autre, tel que dans la doc :
http://www.hibernate.org/hib_docs/v3...irectional-121

[minimarch76]

J'ai donc essayé de suivre les instructions de la doc (merci pour l'info). La requête est désormais correctement formée (tout du moins de la façon dont je l'aurai fait à la main) et ne génère pas d'erreur.

MAIS il me crée une seconde requête permettant de récupérer l'installation, avec un outer join permettant de récupérer l'antivirus. Et en plus, cette dernière requête retourne une erreur (l'identifiant demandé n'est pas présent).

Cela ne marche donc pas.

Est-ce que le fait que la première requête soit issu d'un requêtage effectué par Criteria puisse poser un problème ?

[minimarch76]

Si ça peut aider, voici les nouveaux mapping que j'ai écrit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
<union-subclass name="AntivirusFirewall" table="av_fw">
 
	<property column="numdossier" name="numdossier" not-null="true" type="string" />
 
	<many-to-one name="Installation" cascade="all" fetch="join" class="AntivirusFirewallInstallation" column="iduser" lazy="false" unique="true" insert="false" update="false" />
 
</union-subclass>

et :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
<class name="AntivirusFirewallInstallation" table="av_fw_installation">
 
	<id column="cle" name="Cle" type="string">
		<generator class="foreign">
			<param name="property">AntivirusFireWall</param>
		</generator>
	</id>
 
	<property column="datecreat" name="Date" type="date" />
 
	<one-to-one name="AntivirusFirewall" class="AntivirusFirewall" />
 
</class>

[fr1man]

Comment sont structurées tes tables de BD ?

[minimarch76]

A l'arrache me paraît une bonne réponse, mais je ne pense que c'est celle que tu désire.

Voici pour la table av_fw :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
PK     iduser         varchar(30)

Et pour la table av_fw_installation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
       cle            varchar(24)     (tiens, pas normal ça...)

Je n'ai mis que ce qui importait (c'est un projet professionnel que je reprends, et je n'ai pas l'autorisation de tout mettre, désolé). Le champ "cle" est censé être la clé primaire de "av_fw_installation", mais n'est pas défini comme tel dans la base de données. Les valeurs de ce champ sont les mêmes que les valeurs du champ "iduser" de la table "av_fw".

[fr1man]

A la vue de tes tables, il faudrait plutôt revenir à ton mapping initial, ce qui correspond au deuxième exemple du lien que je t'ai donné.
Ce qui devrait donner:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
<union-subclass name="AntivirusFirewall" table="av_fw">
 
	<property column="numdossier" name="numDossier" not-null="true" type="string" />
 
	<one-to-one cascade="all" fetch="join" class="AntivirusFirewallInstallation" lazy="false" name="Installation" />
 
</union-subclass>

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
<class name="AntivirusFirewallInstallation" table="av_fw_installation">
 
	<id column="cle" name="Cle" type="string">
		<generator class="foreign">
			<param name="property">AntivirusFireWall</param>
		</generator>
	</id>
 
	<property column="datecreat" name="Date" type="date" />
 
	<one-to-one cascade="all" fetch="join" class="AntivirusFirewall" lazy="false" name="AntivirusFireWall" constrained="true"/>
</class>

[minimarch76]

Un grand merki ! Tout fonctionne nickel : le chargement des données comme le requêtage...

Encore un mystère de résolu...