Installationsskripte: Tabellen erstellen oder vorhandene aktualisieren

Ich habe eine Frage, kürzlich habe ich ein Modul mit vielen Tabellen in der Datenbank entwickelt, und das Konzept hat sich häufig geändert. Daher musste ich vorhandene Tabellen in der Datenbank ändern, und ich bemerkte Unterschiede bei der Erstellung von Tabellen, Skripten und der Aktualisierung von Tabellen. Bitte schön. Schauen Sie sich an, wie Sie den folgenden Tabellencode erstellen:

$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
    )
);

Die Funktion newTable () gibt die Instanz von Varien_Db_Ddl_Table zurück. Wenn Sie ein Upgrade des Tabellenskripts durchführen, können Sie der vorhandenen Tabelle auf andere Weise eine neue Spalte hinzufügen.

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

Diese beiden addColumn-Funktionen sind unterschiedlich und auch Methoden verschiedener Klassen. Sie machen mich jedes Mal traurig, wenn ich die Syntax ändern muss. Ist
hier also die Frage, gibt es eine Möglichkeit, eine vorhandene Tabelle mit der Instanz der Varien_Db_Ddl_Table- Klasse zu aktualisieren ?

Es scheint keine Möglichkeit zu geben, eine vorhandene Tabelle mithilfe des Varien_Db_Ddl_Table-Objekts zu ändern. Wenn Sie in den Code für diese Klasse gehen, sehen Sie keinen Bereich, in dem das vorhandene Schema für die Tabelle abgerufen wird, oder Sie überprüfen, ob die Tabelle in irgendeiner Weise vorhanden ist. Dies wäre erforderlich, wenn Sie es zum Ändern der Tabelle verwenden würden.

Darüber hinaus gibt es in Varien_Db_Adapter_Interface keine Methode im Sinne von 'updateTable', die ein Varien_Db_Ddl_Table-Objekt als Parameter verwendet.

Dies ist definitiv einer dieser "Code-Gerüche" in Magento, da zwei völlig unterschiedliche Codeblöcke versuchen, dasselbe auf unterschiedliche Weise zu erreichen. Führt nur zu Fehlern.

Wenn es im Rahmen des Projekts liegt, möchten Sie möglicherweise die Umstellung auf ein EAV-Modell prüfen, wenn sich das Modell wie erwähnt sehr häufig ändert. Dies erspart Ihnen die Mühe, Datenmigrationen hin und her zu verwirren. In diesem Artikel werden die Grundlagen von EAV in Magento erläutert, damit Sie es bewerten und entscheiden können, ob es für Ihr Projekt geeignet ist.