symfony + doctrine + héritage, comment les faire fonctionner?

Question

Je commence à travailler avec Symfony, j'ai trouvé de la documentation sur l'héritage. Mais aussi trouvé this discouraging article, ce qui me fait douter si Doctrine gère l'héritage du tout ...

Quelqu'un trouve-t-il une solution intelligente pour l'héritage dans Symfony + Doctrine?

À titre d'exemple, j'ai déjà structuré la base de données quelque chose comme ceci:

CREATE TABLE `poster` (
    `poster_id` int(11) NOT NULL AUTO_INCREMENT, 
    `user_name` varchar(50) NOT NULL, 
    PRIMARY KEY (`poster_id`), 
    UNIQUE KEY `id` (`poster_id`), 
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=latin1; 

CREATE TABLE `user` (
    `user_id` int(11) NOT NULL, 
    `real_name` varchar(50) DEFAULT NULL, 
    PRIMARY KEY (`user_id`), 
    UNIQUE KEY `user_id` (`user_id`), 
    CONSTRAINT `user_fk` FOREIGN KEY (`user_id`) REFERENCES `poster` (`poster_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=latin1; 

De là, la doctrine a généré cette "schema.yml":

Poster: 
    connection: doctrine 
    tableName: poster 
    columns: 
    poster_id: 
     type: integer(4) 
     fixed: false 
     unsigned: false 
     primary: true 
     autoincrement: true 
    user_name: 
     type: string(50) 
     fixed: false 
     unsigned: false 
     primary: false 
     notnull: true 
     autoincrement: false 
    relations: 
    Post: 
     local: poster_id 
     foreign: poster_id 
     type: many 
    User: 
     local: poster_id 
     foreign: user_id 
     type: many 
    Version: 
     local: poster_id 
     foreign: poster_id 
     type: many 
User: 
    connection: doctrine 
    tableName: user 
    columns: 
    user_id: 
     type: integer(4) 
     fixed: false 
     unsigned: false 
     primary: true 
     autoincrement: false 
    real_name: 
     type: string(50) 
     fixed: false 
     unsigned: false 
     primary: false 
     notnull: false 
     autoincrement: false 
    relations: 
    Poster: 
     local: user_id 
     foreign: poster_id 
     type: one 

Création d'un utilisateur pour cette structure avec les formulaires générés automatiquement par Doctrine ne fonctionne pas.

Toute idée sera appréciée.

Answer 1

Après plusieurs mois de travail sur un projet utilisant à la fois l'agrégation de colonnes et l'héritage concret, je ne peux que dire une chose: rester loin de l'héritage concret! Vraiment. Supposons que vous ayez 3 tables: Média et Vidéo/Audio qui hérite de Média. Vous vous attendez à être en mesure de faire quelque chose comme:

Doctrine_Query::create() 
    ->from('Media m') 
    ->execute(); 

Eh bien, cela ne fonctionnera pas avec l'héritage concret. C'est juste sans valeur et n'a presque aucune utilisation pratique, sauf pour les méthodes d'héritage de modèle.

D'autre part, avec l'agrégation de colonnes, la table des médias aura une colonne « type » automagiquement ajouté, et vous permettra de choses telles que:

Doctrine_Query::create() 
    ->from('Video v') 
    ->execute(); 

qui renvoie une collection d'objets vidéo. Mais vous pouvez également le faire:

Doctrine_Query::create() 
    ->from('Media m') 
    ->execute(); 

Et vous obtiendrez un résultat mixte d'objets vidéo et audio. En tout cas, vous devriez vérifier le doctrine documentation. Mais faites attention car l'héritage et la doctrine peuvent rapidement devenir gênants.

Answer 2

Une solution pour séparer les données « vidéo » de dire des données « audio », mais toujours utiliser la même table pour stocker « médias » est la suivante:

Media: 
    columns: 
    name: { type: string(255), notnull: true } 
    description: { type: text } 

Video: 
    inheritance: 
    type: column_aggregation 
    keyField: type 
    keyValue: video 

Audio: 
    inheritance: 
    type: column_aggregation 
    keyField: type 
    keyValue: audio 

VideoData: 
    columns: 
    resolution_x: { type: integer, notnull: true } 
    resolution_y: { type: integer, notnull: true } 
    relations: 
    Video: { foreignAlias: Data, onDelete: CASCADE } 

AudioData: 
    columns: 
    sample_rate: { type: integer, notnull: true } 
    relations: 
    Audio: { foreignAlias: Data, onDelete: CASCADE } 

Quelque chose comme ça ... De cette façon, vous pouvez stockez tous vos 'médias' dans une table et récupérez-le comme mentionné ci-dessus par DuoSRX et toujours pas de données non pertinentes dans cette table. Bien sûr, vous devez le rejoindre, mais avec des clés étrangères indexées, cela ne devrait pas être du tout un hit de performance.