Warum ist created_at (customer_entity table) so eingestellt, dass es sich beim Update ändert?

Wenn bei der Struktur der Suche customer_entityTisch, bemerkte ich das created_atFeld dieses Attribut hat: on update CURRENT_TIMESTAMP. Jedes Mal, wenn die Zeile aktualisiert wird, created_atändert sich der Zeitstempel.

Anscheinend sollte dieses Attribut auf dem updated_atFeld vorhanden sein, nicht auf dem created_atFeld. Ich weiß, es ist selten, dass diese Tabelle aufgrund der EAV-Struktur direkt geändert wird, aber es scheint immer noch falsch, das created_atFeld jemals zu ändern .

Gibt es einen Grund für diese Tabellenstruktur oder ist es nur ein Fehler?

Bearbeiten: Ich habe einen bestätigten Fehlerbericht von Magento dafür gefunden. Ausgabe # 27944. Leider musst du dich einloggen, um es zu sehen. http://www.magentocommerce.com/bug-tracking/issue?issue=13882

Hier ist was ich gefunden habe. Das Problem tritt nur bei Magento CE 1.6+ (und entsprechenden EE-Versionen) auf. Dies liegt an den neuen Installations- / Upgrade-Skripten, die DDL in Kombination mit MySQL verwenden.
In Versionen vor 1.6 sahen die Spalten created_atund folgendermaßen updated_ataus:

`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+ sieht die ddl so aus:

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

und erzeugt:

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

Der Unterschied besteht darin, dass der defaultWert fehlt.
Und, wie hier beschrieben ,

Weder DEFAULT CURRENT_TIMESTAMP noch ON UPDATE CURRENT_TIMESTAMP entsprechen der Angabe von DEFAULT CURRENT_TIMESTAMP und ON UPDATE CURRENT_TIMESTAMP.

Und da MySQL nur eine Zeitstempelspalte CURRENT_TIMESTAMPals Standard oder für zulässt on update, created_atendet die Spalte so.

Dies ist definitiv ein Magento-Fehler.

Lesen Sie zuerst die Antwort von Marius, um zu sehen, was in der Datenbank passiert.

Ich wollte nur erwähnen, dass die meisten Entwickler nicht auf dieses Problem stoßen, wenn ihr Modell ordnungsgemäß erweitert wird Mage_Core_Model_Abstract. Der Stack sieht folgendermaßen aus:

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

Dies bewirkt Folgendes:

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

Beachten Sie, dass dies bei einigen Ländereinstellungen sowohl in CE> = 1.8.x als auch in EE> = 1.13.x Probleme verursachen kann.

Auch wir haben diesen Fehler gefunden und glauben, dass er auf dem Unterschied zwischen der Datumskodierung in den USA und in Europa beruht.

In den USA sind die Daten in MM-TT-JJJJ angegeben. (02.10.2015 = 10.02.2015). In Europa und vielen anderen Ländern sind die Daten jedoch TT-MM-JJJJ. (02-10-2015 = 2. Oktober 2015 oder 2. Oktober 2015).

Während Magento in den USA ansässig ist, wurde ein Großteil der Entwicklung von Programmierern in der Ukraine durchgeführt. 

Wir haben diesen Fehler mit einer kostenlosen Magento-Erweiterung behoben (damit Sie keinen Magento-Core-Code ändern müssen). Wir haben es auf unserer Website als kostenlosen Download bereitgestellt: http://www.CustomerParadigm.com/download/Magento-Date-Switch-Fix-Extension.zip

Ich habe dies in unserem Blog hier ausführlicher behandelt: http://www.customerparadigm.com/magento-bug-magento-customer-create-date-juxtaposition/

ce 1.9 habe den Fehler in ce 1.8.1 behoben. Unten ist der Unterschied: