Dlaczego parametr create_at (tabela_klienta) ma się zmieniać podczas aktualizacji?

Patrząc na strukturę customer_entitytabeli, zauważyłem, że created_atpole ma ten atrybut: on update CURRENT_TIMESTAMP. Dlatego przy każdej aktualizacji wiersza created_atzmienia się znacznik czasu.

Wygląda na to, że ten atrybut powinien istnieć na updated_atpolu, a nie na created_atpolu. Wiem, że rzadko zdarza się, aby ta tabela była modyfikowana bezpośrednio ze względu na strukturę EAV, ale nadal wydaje się niewłaściwe modyfikowanie created_atpola.

Czy istnieje powód dla takiej struktury tabeli, czy to tylko błąd?

Edycja: Znalazłem w tym celu zgłoszenie błędu z Magento. Wydanie # 27944. Niestety musisz się zalogować, aby go zobaczyć. http://www.magentocommerce.com/bug-tracking/issue?issue=13882

Oto co znalazłem. Problem pojawia się tylko w Magento CE 1.6+ (i pasujących wersjach EE). Wynika to z nowych skryptów instalacji / aktualizacji korzystających z DDL w połączeniu z mysql.
W wersjach wcześniejszych niż 1.6 tak wyglądały kolumny created_ati 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', 

W wersji 1.6+ ddl wygląda następująco:

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

i generuje:

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

Różnica polega na tym, że defaultbrakuje wartości.
I, jak opisano tutaj ,

Bez DEFAULT CURRENT_TIMESTAMP ani ON UPDATE CURRENT_TIMESTAMP, jest to to samo, co określenie zarówno DEFAULT CURRENT_TIMESTAMP, jak i ON UPDATE CURRENT_TIMESTAMP.

A ponieważ MySQL dopuszcza tylko jedną kolumnę ze znacznikiem czasu CURRENT_TIMESTAMPjako domyślną lub dla on update, created_atkolumna kończy się w ten sposób.

To zdecydowanie błąd Magento.

Przede wszystkim przeczytaj odpowiedź Mariusa, aby zobaczyć, co dzieje się w bazie danych.

Chciałem tylko wspomnieć, że większość programistów nie napotka tego problemu, jeśli ich model odpowiednio się rozszerzy Mage_Core_Model_Abstract. Stos wygląda następująco:

1. Your_Model::save połączenia
2. Mage_Core_Model_Abstract::save połączenia
3. Mage_Eav_Model_Entity_Abstract::save połączenia
4. Mage_Eav_Model_Entity_Abstract::_beforeSave połączenia
5. Mage_Eav_Model_Entity_Abstract::walkAttributes połączenia
6. Mage_Eav_Model_Entity_Attribute_Backend_Time_Created::beforeSave

Robi to:

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

Pamiętaj, że może to powodować problemy z niektórymi lokalizacjami zarówno w CE> = 1.8.x, jak i EE> = 1.13.x.

My także znaleźliśmy ten błąd i uważamy, że jest on oparty na różnicy między amerykańskim a europejskim kodowaniem daty.

W Stanach Zjednoczonych daty są zapisywane MM-DD-RRRR. (02-10-2015 = 10 lutego 2015). Ale w Europie i wielu innych miejscach daty są zapisywane DD-MM-RRRR. (02-10-2015 = 2 października 2015 lub 2 października 2015).

Chociaż Magento ma siedzibę w Stanach Zjednoczonych, większość prac rozwojowych została wykonana przez programistów na Ukrainie. 

Naprawiliśmy ten błąd za pomocą bezpłatnego rozszerzenia Magento (abyś nie musiał zmieniać żadnego kodu podstawowego Magento). Udostępniliśmy go na naszej stronie do bezpłatnego pobrania: http://www.CustomerParadigm.com/download/Magento-Date-Switch-Fix-Extension.zip

Omówiłem to bardziej szczegółowo na naszym blogu tutaj: http://www.customerparadigm.com/magento-bug-magento-customer-create-date-juxtaposition/

ce 1.9 naprawiłem błąd w ce 1.8.1 Poniżej znajduje się różnica: