Por que o created_at (tabela customer_entity) está definido para mudar na atualização?

Ao olhar para a estrutura da customer_entitytabela, notei que o created_atcampo tem esse atributo: on update CURRENT_TIMESTAMP. Portanto, toda vez que a linha é atualizada, o created_atcarimbo de data e hora é alterado.

Parece que esse atributo deve existir no updated_atcampo, não no created_atcampo. Eu sei que é raro que esta tabela seja diretamente modificada devido à estrutura do EAV, mas ainda parece errado modificar o created_atcampo.

Existe uma razão para essa estrutura de tabela ou é apenas um bug?

Edit: Encontrei um relatório de bug confirmado do Magento para isso. Edição 27944. Infelizmente, você deve fazer login para visualizá-lo. http://www.magentocommerce.com/bug-tracking/issue?issue=13882

Aqui está o que eu encontrei. O problema aparece apenas no Magento CE 1.6+ (e versões EE correspondentes). É por causa dos novos scripts de instalação / atualização usando DDL em combinação com o mysql.
Nas versões anteriores à 1.6, era assim que as colunas created_ate se updated_atpareciam:

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

No 1.6+, o ddl se parece com isso:

    ->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')

e gera:

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

A diferença é que o defaultvalor está ausente.
E, como descrito aqui ,

Com DEFAULT CURRENT_TIMESTAMP nem ON UPDATE CURRENT_TIMESTAMP, é o mesmo que especificar DEFAULT CURRENT_TIMESTAMP e ON UPDATE CURRENT_TIMESTAMP.

E como o MySQL permite apenas uma coluna de registro de data e hora CURRENT_TIMESTAMPcomo padrão ou para on update, a created_atcoluna termina assim.

Este é definitivamente um bug do Magento.

Antes de tudo, leia a resposta de Marius para ver o que está acontecendo no banco de dados.

Eu só queria mencionar que a maioria dos desenvolvedores não terá esse problema se o modelo deles se estender adequadamente Mage_Core_Model_Abstract. A pilha fica assim:

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

Isso faz o seguinte:

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

Observe que isso pode ter problemas para alguns códigos de idioma em CE> = 1.8.xe EE> = 1.13.x.

Também encontramos esse bug e achamos que ele se baseia na diferença entre a codificação de datas nos EUA e na Europa.

Nos Estados Unidos, as datas são escritas MM-DD-AAAA. (10-02-2015 = 10 de fevereiro de 2015). Mas na Europa e em muitos outros lugares, as datas são escritas DD-MM-AAAA. (10-02-2015 = 2 de outubro de 2015 ou 2 de outubro de 2015).

Enquanto o Magento está sediado nos EUA, grande parte do desenvolvimento foi feito por programadores na Ucrânia. 

Corrigimos esse bug com uma extensão Magento gratuita (para que você não precise alterar nenhum código principal do Magento). Colocamos em nosso site como um download gratuito: http://www.CustomerParadigm.com/download/Magento-Date-Switch-Fix-Extension.zip

Eu cobri isso com mais detalhes em nosso blog aqui: http://www.customerparadigm.com/magento-bug-magento-customer-create-date-juxtaposition/

ce 1.9 corrigiu o erro no ce 1.8.1 Abaixo está o diff: