是否有一个原因Magento不应该支持卸载/降级的模块 [英] is there a reason why Magento shouldn't support uninstall/downgrade for modules

问题描述

自动即时回滚是企业级部署机制的重要特征。目前，使用Magento的内置安装工具无法实现这一点。

鉴于Magento的 core_resource 机制允许顺序执行安装脚本以安装或升级模块（通过执行的SQL和PHP），似乎逻辑IMHO它应该支持相同的过程相反。

现在，一些明显的理由不支持：

1. 回滚脚本是独立的（并且可能是幂等的）将是具有挑战性的。我不认为这是避免这个功能的有效理由，这是一个借口。




2. 其他模块可能依赖于已安装的模块。该模块的xml声明< depends /> 节点可用于标记这些链接。




3. 开发人员可能希望临时禁用模块，而不进行完全卸载。这可能需要xml声明< active /> 节点中的新状态。

对您的想法感兴趣。

JD

解决方案

关于这一点的发布，并且已经调查了相同的SQL部署方案。我必须同意，企业级Magento应该具有内置的这种功能。它的好消息是，至少在一些形式或时尚，我完全不了解。以下是例外情况下的回滚示例：

  try {
 $ write = Mage :: getSingleton（'core /资源 '） - >的getConnection（' core_write'）; 
 $ write-> beginTransaction（）; 
 
 // do stuff here 
 
 $ write-> commit（）; 
} catch（Exception $ e）{
 mage :: log（__ METHOD__。'：'。__LINE__。'：回滚发生。 
 $ write-> rollback（）; 
} 
  

现在，如果你看看app / code / core / Mage / Core /Model/Resource/Setup.php你会发现很多有趣的方法。特别是： _getModifySqlFiles ， _rollbackResourceDb 和 _modifyResourceDb p>

_modifyResourceDb 对我来说最有趣，因为$ actionType这里也可以回滚和卸载 - 还要注意你可以使用PHP文件安装文件。

  //读取资源文件
 $ arrAvailableFiles = array（） ; 
 $ sqlDir = dir（$ sqlFilesDir）; 
 while（false！==（$ sqlFile = $ sqlDir-> read（）））{
 $ matches = array（）; 
 if（preg_match（'＃^'。$ resModel .'-'。$ actionType .'-（。*）\。（sql | php）$＃i'，$ sqlFile，$ matches））{ 
 $ arrAvailableFiles [$ matches [1]] = $ sqlFile; 
} 
} 
  

此代码执行后：

  $ arrModifyFiles = $ this-> _getModifySqlFiles（$ actionType，$ fromVersion，$ toVersion，$ arrAvailableFiles）; 
  

但是，我承认核心Magento开发人员在EAV资源模型的遗漏中迷失了，只需将其部分完成。

  protected function _getModifySqlFiles（$ actionType，$ fromVersion，$ toVersion，$ arrFiles）
 {
 $ arrRes = array（）; 
 
 switch（$ actionType）{
 case'install'：
 case'data-install'：
 ... 
 case'rollback' 
 break; 
 
 case'uninstall'：
 break; 
} 
 return $ arrRes; 
} 
  

我没有机会真正测试以上，但从只是我对ORM的初步调查是magento和自动加载以及另一个开发者对他的发现的投入。

最终，如果我们可以在版本控制的系统中将所有的更改至少保持模块化，那将是最理想的。显然，需要导入的巨大数据集不能以这种方式进行管理，但是对于这些小的增量更改，我想推送到分段，生产测试，如果它失败，则将其恢复一个版本，一切恢复正常。

显然，没有一个理想的解决方案来部署这么多客户端有不同的需求和需求，但是这样做的一般方法将有助于代码/ SQL部署。有一种具有讽刺意味的是，企业有CMS分期，代码模块化开发的能力，但数据库没有得到太多的爱。

有一个相关的问题正在注意到我们现在正在使用一些专门的脚本自制，它们基本上是这样做的：

做一个MySQL转储或备份，然后在BASE_URL中进行替换SQL文件。

最佳做法Magento部署

另一个要查看的工具是 Phing 。

如果有人有时间调查似乎要实施的回滚和卸载流程，并报告他们的发现对我也是有帮助的。

Automated instant rollback is an important feature of enterprise-grade deployment mechanisms. Currently, it's not possible to achieve this using Magento's built-in installation tools.

Given that Magento's core_resource mechanism allows for the sequential execution of setup scripts for installation or upgrade of modules (via execution of SQL and also PHP), it seems logical IMHO that it should support the same process in reverse.

Now, some obvious reasons not to support it:

1. It would be challenging for the rollback scripts to be independent (and possibly idempotent?). I don't see this to be a valid reason to avoid the feature, it's an excuse at best.

2. Other modules might have dependencies on the installed module. The module's xml declaration <depends/> node could be used to flag these linkages.

3. A developer might want to temporarily disable a module without doing a full uninstall. This could require a new status in the xml declaration <active/> node.

Interested in your thoughts.
JD

解决方案

I have seen some postings in regards to such and have investigated the same scenarios for SQL deployment myself. I would have to agree that being Enterprise grade Magento should have this type of functionality built-in. The good news it IS, at least in SOME form or fashion, how complete it is I'm not really sure. Here's a sample of a rollback upon exception:

try {
    $write = Mage::getSingleton('core/resource')->getConnection('core_write');
    $write->beginTransaction();

// do stuff here

    $write->commit();
} catch (Exception $e) {
    mage::log(__METHOD__ . ':' . __LINE__ . ': Rollback happened.');
    $write->rollback();
}

Now if you take a look at app/code/core/Mage/Core/Model/Resource/Setup.php you'll find quite a bit of interesting methods. In particular: _getModifySqlFiles, _rollbackResourceDb and _modifyResourceDb.

_modifyResourceDb is the most interesting to me, since the $actionType here can be rollback and uninstall as well - also note you can use PHP files for your setup files as well.

// Read resource files
$arrAvailableFiles = array();
$sqlDir = dir($sqlFilesDir);
while (false !== ($sqlFile = $sqlDir->read())) {
    $matches = array();
    if (preg_match('#^'.$resModel.'-'.$actionType.'-(.*)\.(sql|php)$#i', $sqlFile, $matches)) {
        $arrAvailableFiles[$matches[1]] = $sqlFile;
    }
}

After this code executes:

$arrModifyFiles = $this->_getModifySqlFiles($actionType, $fromVersion, $toVersion, $arrAvailableFiles);

But heres where I'm assuming core Magento devs got lost in the bowels of the EAV resource model and just left it partially complete.

protected function _getModifySqlFiles($actionType, $fromVersion, $toVersion, $arrFiles)
{
    $arrRes = array();

    switch ($actionType) {
        case 'install':
        case 'data-install':
...
        case 'rollback':
            break;

        case 'uninstall':
            break;
    }
    return $arrRes;
}

I've not had a chance to really test out the above, but from just my initial investigations of the ORM that is magento and the Autoloading as well as another developer's input on his findings as well.

Ultimately it would be ideal if we can keep all of our changes at least module wise within a version controlled system. Obviously huge data sets that need to be imported shouldn't be managed this way but for these small incremental changes I want to push to staging, production test and if it fails pull it back one version and everything is back to normal.

Obviously theres no one ideal solution for deployment with so many clients having different requirements and needs but a general way of doing this would help with code/SQL deployment. It's kind of ironic that Enterprise has CMS staging, and the ability for modular development of code, but the DB has not gotten as much love.

There is a related question that is noting how currently we are doing it with some specialized scripts "home-brewed" that essentially do:

Doing a MySQLDump or backup, then doing a replace on the BASE_URLs in the SQL file.

Best practises for Magento Deployment

Another tool to look at would be Phing.

If anyone has time to investigate the "rollback" and "uninstall" processes that seem to be implemented and report their findings would be helpful to me as well.

这篇关于是否有一个原因Magento不应该支持卸载/降级的模块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！