Perché create_at (tabella customer_entity) è impostato per cambiare in fase di aggiornamento?

Se si guarda alla struttura del customer_entitytavolo, ho notato la created_atcampo ha questo attributo: on update CURRENT_TIMESTAMP. Quindi ogni volta che la riga viene aggiornata, il created_attimestamp cambia.

Sembra che questo attributo dovrebbe esistere sul updated_atcampo, non sul created_atcampo. So che è raro che questa tabella venga modificata direttamente a causa della struttura EAV, ma sembra comunque sbagliato modificare mai il created_atcampo.

C'è una ragione per questa struttura di tabella o è solo un bug?

Modifica: ho trovato una segnalazione di bug confermata da Magento per questo. Numero 27944. Sfortunatamente, devi accedere per vederlo. http://www.magentocommerce.com/bug-tracking/issue?issue=13882

Ecco cosa ho trovato. Il problema si presenta solo su Magento CE 1.6+ (e corrispondenti versioni EE). È a causa dei nuovi script di installazione / aggiornamento che utilizzano DDL in combinazione con mysql.
Nelle versioni precedenti alla 1.6 ecco come apparivano le colonne created_ate 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', 

In 1.6+ il ddl è simile al seguente:

    ->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 genera:

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

La differenza è che defaultmanca il valore.
E, come descritto qui ,

Con DEFAULT CURRENT_TIMESTAMP né ON UPDATE CURRENT_TIMESTAMP, è lo stesso che specificare DEFAULT CURRENT_TIMESTAMP e ON UPDATE CURRENT_TIMESTAMP.

E dal momento che MySQL consente solo una colonna timestamp con CURRENT_TIMESTAMPl'impostazione predefinita o per on update, la created_atcolonna finisce in questo modo.

Questo è sicuramente un bug di Magento.

Prima di tutto, leggi la risposta di Marius per vedere cosa sta succedendo nel database.

Volevo solo ricordare che la maggior parte degli sviluppatori non si imbatterà in questo problema se il loro modello si estende correttamente Mage_Core_Model_Abstract. Lo stack si presenta così:

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

Questo fa quanto segue:

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

Si noti che ciò può avere problemi per alcune versioni locali in entrambi CE> = 1.8.xe EE> = 1.13.x.

Anche noi abbiamo trovato questo errore e pensiamo che sia basato sulla differenza tra la codifica della data americana ed europea.

Negli Stati Uniti, le date sono scritte MM-GG-AAAA. (02-10-2015 = 10 febbraio 2015). Ma in Europa e in molti altri luoghi, le date sono scritte GG-MM-AAAA. (02-10-2015 = 2 ottobre 2015 o 2 ottobre 2015).

Mentre Magento ha sede negli Stati Uniti, gran parte dello sviluppo è stato fatto da programmatori in Ucraina. 

Abbiamo corretto questo errore con un'estensione gratuita di Magento (in modo da non dover modificare alcun codice di base di Magento). Lo abbiamo installato sul nostro sito come download gratuito: http://www.CustomerParadigm.com/download/Magento-Date-Switch-Fix-Extension.zip

L'ho trattato in modo più dettagliato sul nostro blog qui: http://www.customerparadigm.com/magento-bug-magento-customer-create-date-juxtaposition/

ce 1.9 ha corretto il bug in ce 1.8.1 Di seguito è riportato il diff: