Discussion :

[Mohicane]

Bonjour,

Je reviens vers la programmation et me retrouve confronté à un petit problème (technologie employée Springboot; JPA, annotations):
- Soit une entité:

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
import javax.persistence.*;
import java.io.Serializable;
 
@Entity(name = "com.docapost.domain.User")
public class User implements Serializable {
 
    private static final char DN_SEPARATOR = ',';
    private static final String CN_INTRODUCER = "CN=";
 
    @Id
    @GeneratedValue(strategy= GenerationType.AUTO)
    private Long id;
 
    private String dn;
    private String email;
 
    public User() {}
 
    public User(Long id, String dn, String email) {
        this.id = id;
        this.dn = dn;
        this.email = email;
     }
}

Mon problème est le suivant. J'aimerais avoir des classes filles SuperAdmin, Admin, Agent et Consultant héritant de User, déclaré en tant qu'entité et respectant la ddl suivante:

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
CREATE TABLE `user` (
  `id` int(11) NOT NULL,
  `dn` varchar(255) DEFAULT NULL,
  `email` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
 
CREATE TABLE `superadmin` (
  `id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  FOREIGN KEY (`id`) REFERENCES `user`(`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
 
CREATE TABLE `admin` (
  `id` int(11) NOT NULL,
  `id_account` varchar(255) NOT NULL,
  PRIMARY KEY (`id`, `id_account`),
  FOREIGN KEY (`id`) REFERENCES `user`(`id`),
  FOREIGN KEY (`id_account`) REFERENCES `account`(`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
 
CREATE TABLE `agent` (
  `id` int(11) NOT NULL,
  `id_workflow` varchar(255) NOT NULL,
  `id_account` varchar(255) NOT NULL,
  PRIMARY KEY (`id`, `id_workflow`, `id_account`),
  FOREIGN KEY (`id`) REFERENCES `user`(`id`),
  FOREIGN KEY (`id_workflow`, `id_account`) REFERENCES `workflow`(`id`, `id_account`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
 
CREATE TABLE `consultant` (
  `id` int(11) NOT NULL,
  `id_workflow` varchar(255) NOT NULL,
  `id_account` varchar(255) NOT NULL,
  PRIMARY KEY (`id`, `id_workflow`, `id_account`),
  FOREIGN KEY (`id`) REFERENCES `user`(`id`),
  FOREIGN KEY (`id_workflow`, `id_account`) REFERENCES `workflow`(`id`, `id_account`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Je vous passe le détail des tables workflow and co.

J'ai également des Repository pour mes TOUTES mes entités (i.e. SuperAdmin, Admin, Agent, Consultant ET USER)

Jusqu'ici toute mes tentatives de mapping vers la base on fait "péter" mon appli. La solution qui me semblait la plus prometteuse était de déclarer:

Code :

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

1
2
3
4
5
6
7
 
import javax.persistence.Entity;
 
@Entity(name = "com.docapost.domain.SuperAdmin")
public class SuperAdmin extends User {
 
}

Mais il semblerait que les stratégie d'héritage oblige au schéma de table user d'ajouter une colonne rôle (dtype renommé pour mon appli). Je trouve ça bête puisque les éléments qui viennent de la table superadmin seront forcément des superadmin... du coup je vois pas l’intérêt de cette colonne.

Est-ce que quelqu'un a déjà rencontré se genre de cas de figure et a débouché sur une architecture satisfaisante?

[tchize_]

L'intérêt de cette colonne, c'est que JPA sache où aller piocher les données quand tu feras un "select * from User". Ca évite aussi qu'un User soit à la fois SuperAdmin et GuestUser par exemple. Il existe des options pour s'en passer, comme le ClassExtractor d'eclipse Link, mais là il faut savoir ce que tu as comme implémentation derrière.

http://wiki.eclipse.org/EclipseLink/...ClassExtractor

[Mohicane]

Et bien en fait, j'ai trouvé comment faire.

Ma classe User ne change pas (je me suis permis de retirer le paramètre name dans @Entity)
Ma classe Admin extends User et possède également l'annotation @Entity ... et ca marche!?

Je me retrouve bien avec 2 tables:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
CREATE TABLE `user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `dn` varchar(255) DEFAULT NULL,
  `email` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1
 
CREATE TABLE `admin` (
  `id` bigint(20) NOT NULL,
  PRIMARY KEY (`id`),
  CONSTRAINT `FK_user` FOREIGN KEY (`id`) REFERENCES `user` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Je pensais avoir un cas complexe et j'ai surement du tester cette solution dans la journée, mais il y a du y avoir des perturbations interbasedomaincosmiques