Сценарии установки: Создание таблиц по сравнению с обновлением существующих
У меня есть один вопрос, недавно я разрабатывал один модуль с большим количеством таблиц в БД, и концепция часто менялась, поэтому возникла необходимость изменить существующие таблицы в БД, и я заметил разницу в сценарии создания таблиц и обновлении таблиц. Вот, держи. Посмотрите на создание кода таблицы ниже:
$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
)
);
Функция NewTable() возвращает экземпляр varien_db_ddl_table И сценарий обновления таблицы использует другой способ добавления нового столбца в существующую таблицу, взгляните:
$installer->getConnection()
->addColumn($tableName, 'test', array(
'nullable' => false,
'length' => 9,
'type' => Varien_Db_Ddl_Table::TYPE_INTEGER,
'comment' => 'Test Field'
)
)
Эти две функции AddColumn различны, а также являются методами разных классов, и они огорчают меня каждый раз, когда мне нужно изменить синтаксис.
Итак, возникает вопрос, есть ли способ обновить существующую таблицу, используя экземпляр класса varien_db_ddl_table?
2 answers
Похоже, что нет способа изменить существующую таблицу с помощью объекта Varien_Db_Ddl_Table. Если вы войдете в код для этого класса, вы не увидите области, в которой он извлекает существующую схему для таблицы или проверяет, существует ли таблица каким-либо образом. Это было бы необходимо, если бы вы использовали его для изменения таблицы.
Кроме того, в Varien_Db_Adapter_Interface нет метода, аналогичного "UpdateTable", который принимает объект varien_db_ddl_table в качестве параметра.
Это определенно один из тех "запахов кода" в Magento, так как у вас есть два совершенно разных блока кода, пытающихся выполнить одно и то же разными способами. Приведет только к ошибкам.
Если это входит в рамки проекта, вы можете рассмотреть возможность перехода на модель подслушивания, если модель меняется очень часто, как вы упомянули. Это может избавить вас от необходимости путать миграцию данных туда и обратно. Вот статья , в которой объясняются основы EAV в Magento, чтобы вы могли оценить ее и решить, подходит ли она для вашего проекта.