php - ¿Hay alguna razón por la cual Magento no debería admitir la desinstalación/degradación de los módulos?

sql deployment

Question

La reversión instantánea automatizada es una característica importante de los mecanismos de implementación de nivel empresarial. Actualmente, no es posible lograr esto utilizando las herramientas de instalación integradas de Magento.

Dado que el mecanismo core_resource de Magento permite la ejecución secuencial de scripts de instalación para la instalación o actualización de módulos (a través de la ejecución de SQL y también PHP), parece lógico en mi humilde opinión que apoye el mismo proceso al revés.

Ahora, algunas razones obvias para no apoyarlo:

1. Sería desafiante que los scripts de reversión sean independientes (y posiblemente idempotentes). No veo que esta sea una razón válida para evitar la función, es una excusa en el mejor de los casos.

2. Otros módulos pueden tener dependencias en el módulo instalado. El nodo de declaración xml <depends/> del módulo podría usarse para marcar estos enlaces.

3. Un desarrollador puede querer deshabilitar temporalmente un módulo sin realizar una desinstalación completa. Esto podría requerir un nuevo estado en el nodo <active/> la declaración xml.

Interesado en tus pensamientos
JD

Answer 1

Nota: Quizás esto no sea aplicable a Magento.

Normalmente veo actualizaciones de aplicaciones de bases de datos que cubren dos áreas principales: 1. código 2. base de datos.

Las actualizaciones de código son fáciles de revertir. Normalmente administro esto por separado del código de actualización / administración de las aplicaciones. Usualmente uso un sistema de archivos del sistema operativo para proporcionarme la funcionalidad de "reversión instantánea". En lo que respecta a la reversión de bases de datos, las cosas se vuelven más complicadas. Uno podría tener un enfoque similar con la base de datos también. Sin embargo, solo sería realista en un sistema de prueba.

Si lo que le preocupa es solo la reversión del código, usaría algo externo de la aplicación para administrarlo. Se puede pensar como una instantánea, supongo.

Si Magento no es compatible con esto de manera inmediata, no creo que sea aconsejable hacerlo. Parece un requisito básico que, si no se planifica y codifica desde el principio, será bastante difícil de implementar.

Answer 2

1. Me acuerdo de mi propia pregunta en la que Ivan Chepurnyi te dijo:

   @Jonathan espera que Magento 2.0 sea más amigable para los desarrolladores, especialmente en lo que respecta a las actualizaciones de la base de datos. Pero, por supuesto, solo se extenderá Zend_Db. El uso de Doctrine 2.0 orm resolvería el problema, pero es necesario volver a escribir Magento desde cero :)

   No conozco Doctrine, pero a partir de la lectura de su mapeo, el esquema se describe en los comentarios de PHPDoc para las clases (supuestamente recogidas por reflexión ) que luego se convierten en consultas de forma transparente. No hay necesidad de scripts de configuración. Esto debe significar que una reversión es lo mismo que una degradación, instalar las clases de versiones anteriores y sus comentarios, y el resto simplemente sucede.

   Conociendo a Magento, probablemente no retrocederían ni alterarían el código anterior, sino que ofrecerían un método de configuración alternativo utilizando archivos XML incrementales, aunque sin espacio de nombres. Retirar una versión aquí significaría invertir la diferencia como se describe en cada archivo.
   Yo también preferiría esto, ya que significa que sería posible implementar instrucciones como insertar registros predeterminados, algo que no creo que logre Doctrine. Y coexiste con las versiones anteriores al cambio. ¿Vas a hacer una solicitud de función ?

2. Los números de versión en <depends/> parecen lógicos.

3. Realmente no tengo un tercer punto, pero quería completar el set. :RE

Editar:
Olvidé responder la pregunta. No, no hay una razón por la cual Magento no debería respaldar las rebajas, al menos no si estaban dispuestos a esforzarse.

Answer 3

He visto algunas publicaciones sobre esto y he investigado los mismos escenarios para el despliegue de SQL. Tendría que aceptar que ser Magento de nivel empresarial debería tener este tipo de funcionalidad incorporada. La buena noticia es que, al menos en ALGUNA forma o moda, qué tan completa es, no estoy realmente seguro. Aquí hay una muestra de una reversión a excepción:

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();
}

Ahora, si echa un vistazo a la aplicación / code / core / Mage / Core / Model / Resource / Setup.php, encontrará un buen número de métodos interesantes. En particular: _getModifySqlFiles , _rollbackResourceDb y _modifyResourceDb .

_modifyResourceDb es lo más interesante para mí, ya que el $ actionType aquí también puede retrotraerse y desinstalarse; también tenga en cuenta que también puede usar archivos PHP para sus archivos de instalación.

// 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;
    }
}

Después de que este código se ejecuta:

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

Pero aquí es donde asumo que los desarrolladores centrales de Magento se perdieron en las entrañas del modelo de recursos de EAV y simplemente lo dejaron parcialmente completo.

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

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

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

No he tenido la oportunidad de poner a prueba realmente lo anterior, sino solo de mis primeras investigaciones del ORM que es magento y Autoloading, así como las opiniones de otro desarrollador sobre sus hallazgos también.

En última instancia, sería ideal si podemos mantener todos nuestros cambios al menos en lo que respecta al módulo dentro de un sistema controlado por versión. Obviamente, los grandes conjuntos de datos que se deben importar no se deben administrar de esta manera, sino que para estos pequeños cambios incrementales quiero pasar a la etapa de prueba de producción y, si falla, retirar una versión y todo vuelve a la normalidad.

Obviamente, no hay una solución ideal para el despliegue con tantos clientes que tienen diferentes requisitos y necesidades, pero una forma general de hacerlo sería de ayuda con la implementación de código / SQL. Es un poco irónico que Enterprise tenga puesta en escena CMS, y la capacidad para el desarrollo modular de código, pero el DB no ha recibido tanto amor.

Hay una pregunta relacionada que señala cómo actualmente lo estamos haciendo con algunos guiones especializados "hechos en casa" que esencialmente hacen:

Hacer un MySQLDump o una copia de seguridad, luego hacer un reemplazo en BASE_URLs en el archivo SQL.

Mejores prácticas para la implementación de Magento

Otra herramienta para mirar sería Phing .

Si alguien tiene tiempo para investigar los procesos de "revertir" y "desinstalar" que parecen implementarse y reportar sus hallazgos, también sería útil para mí.