Installer des scripts: créer des tables ou mettre à jour des tables existantes

J'ai une question, récemment je développais un module avec beaucoup de tables dans la base de données, et le concept changeait souvent, donc il fallait changer les tables existantes dans la base de données, et j'ai remarqué une différence dans la création de script de création de table et la mise à niveau de table. Voici. Regardez la création du code de table ci-dessous:

$table = $installer->getConnection()
    ->newTable($installer->getTable('module/table'))
    ->addColumn('id', Varien_Db_Ddl_Table::TYPE_INTEGER, 9, array(
        'nullable' => false,
        'primary' => true,
        'identity' => true,
        'auto_increment' => true
    )
);

la fonction newTable () renvoie une instance de Varien_Db_Ddl_Table Et la mise à niveau du script de table utilise une manière différente pour ajouter une nouvelle colonne à la table existante, jetez un œil:

$installer->getConnection()
    ->addColumn($tableName, 'test', array(
        'nullable' => false,
        'length' => 9,
        'type' => Varien_Db_Ddl_Table::TYPE_INTEGER,
        'comment' => 'Test Field'
    )
)

ces deux fonctions addColumn sont différentes et ce sont aussi des méthodes de classes différentes, et elles me rendent triste à chaque fois que je dois changer de syntaxe.
Donc, voici la question, est-il possible de mettre à jour la table existante en utilisant l'instance de la classe Varien_Db_Ddl_Table ?

Il ne semble pas y avoir de moyen de modifier une table existante à l'aide de l'objet Varien_Db_Ddl_Table. Si vous entrez dans le code de cette classe, vous ne verrez aucune zone dans laquelle il extrait le schéma existant de la table, ou vérifie même si la table existe de quelque manière que ce soit. Cela serait nécessaire si vous deviez l'utiliser pour modifier la table.

De plus, dans Varien_Db_Adapter_Interface, il n'y a pas de méthode du type «updateTable» qui prend un objet Varien_Db_Ddl_Table comme paramètre.

C'est certainement l'une de ces «odeurs de code» dans Magento, car vous avez deux blocs de code complètement différents qui tentent d'accomplir la même chose de différentes manières. Ne conduira qu'à des bugs.

Si cela entre dans le cadre du projet, vous voudrez peut-être envisager de passer à un modèle EAV si le modèle change très fréquemment comme vous l'avez mentionné. Cela peut vous éviter de confondre les migrations de données dans les deux sens. Voici un article qui explique les bases de l'EAV dans Magento afin que vous puissiez l'évaluer et décider s'il convient à votre projet.