¿Por qué se crea created_at (tabla customer_entity) para cambiar en la actualización?

Al mirar la estructura de la customer_entitymesa, me di cuenta el created_atcampo tiene este atributo: on update CURRENT_TIMESTAMP. Por lo tanto, cada vez que se actualiza la fila, la created_atmarca de tiempo cambia.

Parece que este atributo debería existir en el updated_atcampo, no en el created_atcampo. Sé que es raro que esta tabla se modifique directamente debido a la estructura EAV, pero aún parece incorrecto modificar el created_atcampo.

¿Hay alguna razón para esta estructura de tabla, o es solo un error?

Editar: Encontré un informe de error confirmado de Magento para esto. Edición # 27944. Desafortunadamente, debe iniciar sesión para verlo. http://www.magentocommerce.com/bug-tracking/issue?issue=13882

Aquí está lo que encontré. El problema solo aparece en Magento CE 1.6+ (y las versiones EE correspondientes). Se debe a los nuevos scripts de instalación / actualización que utilizan DDL en combinación con mysql.
En versiones anteriores a 1.6, así es como se veían las columnas created_aty updated_at:

`created_at` datetime NOT NULL default '0000-00-00 00:00:00',
`updated_at` datetime NOT NULL default '0000-00-00 00:00:00', 

En 1.6+ el ddl se ve así:

    ->addColumn('created_at', Varien_Db_Ddl_Table::TYPE_TIMESTAMP, null, array(
        'nullable'  => false,
        ), 'Created At')
    ->addColumn('updated_at', Varien_Db_Ddl_Table::TYPE_TIMESTAMP, null, array(
        'nullable'  => false,
        ), 'Updated At')

y genera:

`created_at` timestamp NOT NULL COMMENT 'Created At',
`updated_at` timestamp NOT NULL COMMENT 'Updated At',

La diferencia es que defaultfalta el valor.
Y, como se describe aquí ,

Sin DEFAULT CURRENT_TIMESTAMP ni ON UPDATE CURRENT_TIMESTAMP, es lo mismo que especificar DEFAULT CURRENT_TIMESTAMP y ON UPDATE CURRENT_TIMESTAMP.

Y dado que MySQL solo permite una columna de marca de tiempo con el CURRENT_TIMESTAMPvalor predeterminado o para on update, la created_atcolumna termina así.

Este es definitivamente un error de Magento.

En primer lugar, lea la respuesta de Marius para ver qué sucede en la base de datos.

Solo quería mencionar que la mayoría de los desarrolladores no se encontrarán con este problema si su modelo se extiende correctamente Mage_Core_Model_Abstract. La pila se ve así:

1. Your_Model::save llamadas
2. Mage_Core_Model_Abstract::save llamadas
3. Mage_Eav_Model_Entity_Abstract::save llamadas
4. Mage_Eav_Model_Entity_Abstract::_beforeSave llamadas
5. Mage_Eav_Model_Entity_Abstract::walkAttributes llamadas
6. Mage_Eav_Model_Entity_Attribute_Backend_Time_Created::beforeSave

Esto hace lo siguiente:

$attributeCode = $this->getAttribute()->getAttributeCode();
$date = $object->getData($attributeCode);
if (is_null($date)) {
    if ($object->isObjectNew()) {
        $object->setData($attributeCode, Varien_Date::now());
    }
}

Solo tenga en cuenta que esto puede tener problemas para algunas configuraciones regionales en CE> = 1.8.xy EE> = 1.13.x.

Nosotros también encontramos este error y creemos que se basa en la diferencia entre la codificación de fechas de EE. UU. Y Europa.

En los Estados Unidos, las fechas se escriben MM-DD-AAAA. (02-10-2015 = 10 de febrero de 2015). Pero en Europa y en muchos otros lugares, las fechas están escritas DD-MM-AAAA. (02-10-2015 = 2 de octubre de 2015 o 2 de octubre de 2015).

Si bien Magento tiene su sede en los EE. UU., Gran parte del desarrollo fue realizado por programadores en Ucrania. 

Hemos solucionado este error con una extensión gratuita de Magento (para que no tenga que cambiar ningún código de núcleo de Magento). Lo hemos puesto en nuestro sitio como descarga gratuita: http://www.CustomerParadigm.com/download/Magento-Date-Switch-Fix-Extension.zip

He cubierto esto con más detalle en nuestro blog aquí: http://www.customerparadigm.com/magento-bug-magento-customer-create-date-juxtaposition/

ce 1.9 ha corregido el error en ce 1.8.1 A continuación se muestra la diferencia: