column_aggregation + formulaire admin generator

Bonjour à tous,

Je suis actuellement sur une problématique de génération de schéma / formulaire / admin generator dont je n'arrive pas à me sortir.

L'idée est d'avoir une classe Parent, deux classes Fils1 et Fils2, la classe parent étant relié à une table ProprieteParent sous formes 1-n ( un parent à une ou plusieurs propriétés ), et les classes Fils1 et Fils2 définissant des champs supplémentaires et des relations 1-n ou n-m supplémentaires (ouf)

Voici l'idée du schéma:

Code:

---

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

Parent: columns: name: {type: string } relations: ProprieteParent : { local: id, foreign: parent_id, type: many }   ProprieteParent: columns: parent_id: {type: integer } key: {type: integer } value: {type: string }   Fils1: inheritance: type: column_aggregation extends: Parent columns: other1: {type: string }   Fils2: inheritance: type: column_aggregation extends: Parent columns: other2: {type: string }

---

Je ne détaille pas les relations des fils, elles peuvent être de toute nature (1-n, n-1, n-m).

Déjà, sans vouloir cracher dans la soupe de Doctrine qui jusqu'ici m'avait servit fidèlement, les modèles d'héritage sont vraiment trop simpliste ou pas assez paramétrable.
J'aurais préféré ici passer par de l'héritage "concrete", mais la relation 1-n sur la table Parent me l'interdit, car cette table ne sera jamais remplis, donc pas de match d'ID possible entre les deux tables.

Quoiqu'il en soit, ce schéma fonctionne, mais mon problème est que la génération automatique du schéma me créé un formulaire Parent qui contient tout les champs des tables Fils1 et Fils2, et que ainsi, quand j'affiche le formulaire du Fils1 ou Fils2, il contient tout les champs de Parent+Fils1+Fils2.

Y aurait'il un point qui m'aurait échapper ou faut il que je redéfinisse dans chacun de mes forms fils la liste des champs à réellement afficher ?

Ce behavior n'est il pas justement censé répondre à cette attente en stockant les bons attributs et méthodes dans les classes fils et ne pas tout bourrés dans la classe parente sans distinction ?
Cela revient à créer une table qui contiendrait elle-même tout les champs, cette héritage me semble vraiment très pauvre et cela m'étonne 8O

Merci d'avance :)

Citation:

---

J'aurais préféré ici passer par de l'héritage "concrete", mais la relation 1-n sur la table Parent me l'interdit, car cette table ne sera jamais remplis, donc pas de match d'ID possible entre les deux tables.

---

La table Parent est une table 'fictive', tu ne peux pas l'utiliser dans ton application. Il faut définir les relations au niveau des tables réelles, qui sont les tables Enfant1 & 2 et tu peux alors passer par l'héritage 'concrete' :

Code:

---

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

Parent: columns: name: {type: string }   ProprieteParent: columns: parent_id: {type: integer } key: {type: integer } value: {type: string }   Fils1: inheritance: type: concrete extends: Parent columns: other1: {type: string } relations: ProprieteParent : { local: id, foreign: parent_id, type: many }   Fils2: inheritance: type: concrete extends: Parent columns: other2: {type: string } relations: ProprieteParent : { local: id, foreign: parent_id, type: many }

---

... et en complément, comme me le signale fort diplomatiquement Michel par MP :

Citation:

---

La réponse est bonne, mais je me permettrais juste de rajouter qu'il n'est pas nécessaire de définir le type qui sera vu comme un 1-n par défaut. Par contre, il conviendrait de préciser les foreignAlias pour rendre le modèle objet généré plus clair.

---

Citation:

---

La table Parent est une table 'fictive', tu ne peux pas l'utiliser dans ton application. Il faut définir les relations au niveau des tables réelles, qui sont les tables Enfant1 & 2 et tu peux alors passer par l'héritage 'concrete' :

---

En effet, j'avais bien compris cette logique (qui ne l'est pas d'ailleurs), mais comme je l'ai expliqué, mes tables Fils1 et Fils2 vont avoir beaucoup de relation 1-n et n-m, impensable pour moi de devoir dupliquer toutes ces tables pour chaque fils alors qu'elle pourrait se retrouver aggréger sur le père ( ce qui serait logique ).

Quoiqu'il en soit, le type de problématique que je décris n'est visiblement pas solutionable via l'héritage Doctrine couplé à Symfony qui est bien trop simpliste.

Pour ceux qui rencontrerait ce type de problématique, la meilleure solution est sans doute de passer par une relation one-to-one comme ceci:

Code:

---

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

Parent: columns: name: {type: string } relations: ProprieteParent : { local: id, foreign: parent_id, type: many }   ProprieteParent: columns: parent_id: {type: integer } key: {type: integer } value: {type: string }   Fils1: columns: parent_id: {type: integer } other1: {type: string } relations: Parent: { local: parent_id, foreign: id, type: one, foreignType: one }   Fils2: columns: parent_id: {type: integer } other2: {type: string } relations: Parent: { local: parent_id, foreign: id, type: one, foreignType: one }

---

Puis, dans les form des enfants côté symfony, un simple

Code:

---

1 2	$this->embedRelation('Membre');

---

Permet d'embed le parent dans les fils et de tout faire ( magie magie ).
Ainsi on edite le père et l'enfant en même temps, cela réplique un fonctionnement d'heritage, et permet de gérer toutes les problématiques décrites avant, soit:
> Relations 1-n, n-1, n-m sur le père
> Relations 1-n, n-1, n-m sur les enfants, qui peuvent être différentes
> Intégration simple, efficace, propre et sans réécriture massive dans Symfo
> BDD sans réplicaton massive, découpage logique et propre des tables

En esperant que ca puisse aider :)

Effectivement, l'héritage n'est pas vraiment fait pour régler des problèmes aussi lourd de relation.

Avec ce type d'héritage, il n'y a qu'une table physique sous-jacente, ce que tend à faire oublier le modèle objet. Toutes les relations de tout les enfants doivent s'y retrouver et y cohabiter (dans la table physique) ce qui n'est souvent pas possible.

La solution que tu proposes me semble le meilleur compromis.