Discussion :

[nawfal_saber]

Bonjour,

Je suis en train de modéliser un réseau en utilisant JPA. Mon réseau est non circulaire, il est constitué d'un ensemble d'entités (MonEntite -> table_mes_entites) reliés entre eux avec une relation de type ManyToMany sur la même entité (donc une table de jointure avec deux colonnes source_id et destination_id, les deux constituent la clé primaire de la table de jointure et il n'y a pas de colonnes supplémentaire dans cette table).
Exemple :

Code :

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

1
2
Entité1 -> Entité2 -> Entité3 -> Entité5 -> Entité6
       -> Entité4 -> Entité3              -> Entité7

J'ai effectué le mapping de deux manières mais les deux ne marchent pas, et mes entités ne sont par reliées en base. Voila un extrait du code :

Méthode 1:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
@Entity
public class Entite {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    private Integer id;
 
 @JoinTable(name = "relations_entites", joinColumns = {@JoinColumn(name = "source_id", referencedColumnName = "id")}, inverseJoinColumns = {@JoinColumn(name = "destination_id", referencedColumnName = "id")})
 @ManyToMany
 private List<Entite> prochainesEntites;
}

Méthode 2:
Cette méthode que j'ai trouvé sur le net, consiste à créer une classe intermédiaire et transformer la relation ManyToMany à ManyToOne puis OneToeMany

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
@Entity
public class Entite implements Serializable {
 id ....
 
 @OneToMany(mappedBy="entiteSource")
 private List<RelationEntite> relationsEntite;
}
 
@Entity
public class RelationEntite implements Serializable {
 
    @EmbeddedId
    private RelationEntiteId id;
 
    @ManyToOne
    @JoinColumn(name="source_id", insertable=false, updatable=false)
    private Entite entiteSource;
 
    @ManyToOne
    @JoinColumn(name="destination_id", insertable=false, updatable=false)
    private Entite entiteDestination;
 
    @Embeddable
    public static class RelationEntiteId implements Serializable {
 
        @Column(name="source_id", nullable=false, updatable=false)
        private Integer sourceId;
 
        @Column(name="destination_id", nullable=false, updatable=false)
        private Integer destinationId;
 
        @Override
        public boolean equals(Object o) {
            if(o == null) {
                return false;
            }
 
            if(!(o instanceof RelationEntiteId)) {
                return false;
            }
 
            RelationEntiteId other = (RelationEntiteId) o;
            if(!(other.sourceId.equals(sourceId))) {
                return false;
            }
 
            if(!(other.destinationId.equals(destinationId))) {
                return false;
            }
 
            return true;
        }
}

Ci-dessous une vue sur ma base :

Code :

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

1
2
3
4
5
6
7
8
9
Table mes_entites:
------------------------
| id | nom | description |
------------------------
 
Table de jointure relations_entites (les deux clés étrangères pointent sur la même table mes_entites)
----------------------------
| source_id | destination_id |
----------------------------

Avez vous une idée d'où peut venir mon problème ? Quelle méthode (corrigé ) des deux préconisez vous ?

Merci d'avance

[JeitEmgie]

Aucune des deux méthodes ne permet de représenter correctement votre réseau, car vous ne conservez nulle part l'ordre des "prochainesEntites".

Prenons Entité1 dans la méthode 1 (le problème est similaire pour la 2):
à la création vous allez ajouter "Entité2, Entité3, Entité5, Entité6" dans cette ordre dans la List<>, cependant rien ne garantit qu'à la relecture l'ordre soit le même (vous dépendrez du comportement de la DB) : vous devez avoir un moyen d'ordonner la liste avec un @OrderBy sur un champ à ajouter (un int qui contiendra le numéro d'ordre dans la liste), ce qui implique d'avoir aussi les méthodes d'ajout, insertion et suppression de "prochaines entités" qui en tiennent compte.



NB
vous avez oublié le "implements Serializable" dans la première méthode et le referencedColumnName ne sert à rien, et peut même être la source du problème.

[nawfal_saber]

Merci d'abord pour votre réponse.

Concernant votre remarque sur l'ordre, en faite je compte stocker dans "prochainesEntites" que les prochaines entités de niveau n+1, dans mon exemple la liste des "prochainesEntites" pour l'entité 1 contiendra (Entité2, Entité4); ainsi pour chaque noeud du réseau j'ai les éléments suivants (grâce à mon mapping qui ne marche pas) et je peux parcourir l'arbre correctement.


Pour l’implémentation du Serializable, effectivement je ne l'ai pas mis dans mon exemple mais je l'ai fait donc mon code et pour le referencedColumnName je vais essayer sans voir ce que ça donne. Merci

[JeitEmgie]

Merci d'abord pour votre réponse.

Concernant votre remarque sur l'ordre, en faite je compte stocker dans "prochainesEntites" que les prochaines entités de niveau n+1, dans mon exemple la liste des "prochainesEntites" pour l'entité 1 contiendra (Entité2, Entité4); ainsi pour chaque noeud du réseau j'ai les éléments suivants (grâce à mon mapping qui ne marche pas) et je peux parcourir l'arbre correctement.


Pour l’implémentation du Serializable, effectivement je ne l'ai pas mis dans mon exemple mais je l'ai fait donc mon code et pour le referencedColumnName je vais essayer sans voir ce que ça donne. Merci

Votre représentation

Code :

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

1
2
3
 
1 Entité1 -> Entité2 -> Entité3 -> Entité5 -> Entité6
2           -> Entité4 -> Entité3              -> Entité7

peut induire une ambiguïté : on ne sait pas si à chaque étape on a un choix libre de contrainte ou si comme un réseau de transport, il s'agit de "lignes" (auquel cas on a toujours le choix, mais cela peut impliquer un "changement" de "transport")

Dans le premier cas cela signifierait que l'on pourrait voyager
(1,2,3,5,6), (1,2,3,5,7), (1,4,3,5,6), (1,4,3,5,7) etc sans jamais changer de "transport"
Dans le second uniquement
(1,2,3,5,6), (1,4,3,5,7)
la "ligne" qui va de 1 à 7 sans changement passe obligatoirement par 4, par contre le voyageur qui va de 1 à 7 peut aussi passer par 2 mais doit alors changer en 3.
Et pour gérer ce deuxième modèle, vous auriez besoin aussi de stocker cette notion de "ligne".

Il faut rester attentif aux "questions" auxquels votre modèle devra répondre pour faire les bons choix d'implémentation.

[nawfal_saber]

Oui, effectivement mon exemple n'était peut être pas claire.
Alors moi je veux modéliser ce que vous avez cité dans votre premier cas ((1,2,3,5,6), (1,2,3,5,7), (1,4,3,5,6), (1,4,3,5,7) ) c'est à dire à chaque étape j'ai un choix à faire.

Quelle implémentation conseillez vous ? Merci

[JeitEmgie]

Oui, effectivement mon exemple n'était peut être pas claire.
Alors moi je veux modéliser ce que vous avez cité dans votre premier cas ((1,2,3,5,6), (1,2,3,5,7), (1,4,3,5,6), (1,4,3,5,7) ) c'est à dire à chaque étape j'ai un choix à faire.

Quelle implémentation conseillez vous ? Merci

Tant que vous n'explicitez pas les questions auxquelles doit répondre votre modèle...

Déjà que si vos "Entités" ne contienne aucune information autre que leur "id", il est difficile de justifier pourquoi vous en faites des class/@Entity... un graphe peut très bien se décrire par des structures de données classiques (par exemple un tableau et ses variantes optimisées pour les cas "creux"...) sans besoin d'en faire des classes.