is there a reason why Magento shouldn't support uninstall/downgrade for modules

问题

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

回答1:

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 practices 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.

回答2:

1. I'm reminded of my own question where Ivan Chepurnyi said to you:

   @Jonathan hope Magento 2.0 will be more developer friendly, especially in a way of database upgrades. But of course it just will be extended Zend_Db. Using of Doctrine 2.0 orm would solve the this issue, but it requires to rewrite Magento from scratch :)

   I don't know Doctrine but from reading of it's mapping the schema is described in PHPDoc comments for classes (presumably garnered by reflection) which are then converted into queries transparently. There is no need for setup scripts. This must mean a rollback is the same as a downgrade, install the previous version classes and their comments and the rest just happens.

   Knowing Magento they probably wouldn't go back and upset old code but instead offer an alternative setup method using incremental XML files - albeit with no namespace. Rolling back a version here would mean inverting the difference as described in each file.
   I would prefer this way too as it means instructions like inserting default records would be possible, something I don't think Doctrine manages. And it coexists with versions previous to the change. Are you going to make a feature request?

2. Version numbers in <depends/> seems logical.

3. I don't really have a third point but I wanted to complete the set. :D

Edit:
I forgot to answer the question. No, there isn't a reason why Magento shouldn't support downgrades, at least not if they were willing to put the effort in.

回答3:

Note: Perhaps this is not applicable to Magento.

I usually view database application upgrades covering two main areas: 1. code 2. database.

Code updates are easy to roll back. I usually manage this separately of the applications upgrade/management code. I usually use a the OS's file system to provide me with "instant rollback" functionality. Where database roll-backs are concerned, things get more complicated. One could take a similar approach with the database as well. However, it would only be realistic on a test system.

If it's only code rollback that you are concerned with, I'd use something external of the application itself to manage this. It can be thought of as a snapshot I suppose.

If Magento doesn't support this out of the box, I don't think it would be wise to tack it on. It seems like quite a core requirement that if not planned and coded for from the start, will be rather tricky to implement.

来源：https://stackoverflow.com/questions/5294385/is-there-a-reason-why-magento-shouldnt-support-uninstall-downgrade-for-modules