Installa script: creazione di tabelle e aggiornamento di quelle esistenti

ho una domanda, recentemente stavo sviluppando un modulo con molte tabelle in DB, e il concetto cambiava spesso, quindi era necessario cambiare le tabelle esistenti in DB e ho notato differenze nella creazione di script e aggiornamento di tabelle. Ecco qui. Guarda come creare il codice tabella di seguito:

$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 funzione newTable () restituisce l'istanza di Varien_Db_Ddl_Table E l'aggiornamento dello script della tabella utilizza un modo diverso per aggiungere una nuova colonna alla tabella esistente, dai un'occhiata:

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

queste due funzioni addColumn sono diverse e inoltre sono metodi di classi diverse e mi rendono triste ogni volta che devo cambiare la sintassi.
Quindi, ecco la domanda, c'è un modo per aggiornare la tabella esistente usando l'istanza della classe Varien_Db_Ddl_Table ?

Non sembra esserci un modo per modificare una tabella esistente usando l'oggetto Varien_Db_Ddl_Table. Se si inserisce il codice per quella classe, non verrà visualizzata alcuna area in cui viene inserito lo schema esistente per la tabella o verrà verificato se la tabella esiste in qualche modo. Ciò sarebbe necessario se lo si usasse per modificare la tabella.

Inoltre, in Varien_Db_Adapter_Interface non esiste un metodo lungo le righe di 'updateTable' che accetta un oggetto Varien_Db_Ddl_Table come parametro.

Questo è sicuramente uno di quegli "odori di codice" in Magento, poiché hai due blocchi completamente diversi di codice che tentano di ottenere la stessa cosa in modi diversi. Porterà solo a bug.

Se rientra nell'ambito del progetto, ti consigliamo di passare a un modello EAV se il modello cambia molto frequentemente, come hai già detto. Questo può farti risparmiare il problema di confondere le migrazioni dei dati avanti e indietro. Ecco un articolo che spiega le basi di EAV in Magento in modo che tu possa valutarlo e decidere se è appropriato per il tuo progetto.