Почему create_at (таблица customer_entity) изменяется при обновлении?

При взгляде на структуру customer_entityтаблицы, я заметил , что created_atполе имеет этот атрибут: on update CURRENT_TIMESTAMP. Таким образом, каждый раз, когда строка обновляется, created_atотметка времени изменяется.

Кажется, этот атрибут должен существовать на updated_atполе, а не на created_atполе. Я знаю, что редко эта таблица модифицируется напрямую из-за структуры EAV, но все равно кажется неправильным модифицировать created_atполе.

Есть ли причина для этой структуры таблицы, или это просто ошибка?

Изменить: я нашел подтвержденный отчет об ошибке от Magento для этого. Выпуск № 27944. К сожалению, вы должны войти, чтобы просмотреть его. http://www.magentocommerce.com/bug-tracking/issue?issue=13882

Вот что я нашел. Проблема появляется только в Magento CE 1.6+ (и соответствующих версиях EE). Это из-за новых скриптов установки / обновления, использующих DDL в сочетании с mysql.
В версиях до 1.6 это, как created_atи 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', 

В 1.6+ ddl выглядит так:

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

и генерирует:

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

Разница в том, что defaultзначение отсутствует.
И, как описано здесь ,

Ни с DEFAULT CURRENT_TIMESTAMP, ни с ON UPDATE CURRENT_TIMESTAMP, это то же самое, что указать DEFAULT CURRENT_TIMESTAMP и ON UPDATE CURRENT_TIMESTAMP.

А поскольку MySQL допускает только один столбец отметки времени со CURRENT_TIMESTAMPзначением по умолчанию или для on update, created_atстолбец заканчивается следующим образом.

Это определенно ошибка Magento.

Прежде всего, прочитайте ответ Мариуса, чтобы увидеть, что происходит в базе данных.

Я просто хотел упомянуть, что большинство разработчиков не столкнется с этой проблемой, если их модель должным образом расширится Mage_Core_Model_Abstract. Стек выглядит так:

1. Your_Model::save звонки
2. Mage_Core_Model_Abstract::save звонки
3. Mage_Eav_Model_Entity_Abstract::save звонки
4. Mage_Eav_Model_Entity_Abstract::_beforeSave звонки
5. Mage_Eav_Model_Entity_Abstract::walkAttributes звонки
6. Mage_Eav_Model_Entity_Attribute_Backend_Time_Created::beforeSave

Это делает следующее:

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

Просто отметьте, что это может иметь проблемы для некоторых локалей как в CE> = 1.8.x, так и в EE> = 1.13.x.

Мы тоже нашли эту ошибку и думаем, что она основана на разнице между американским и европейским кодированием дат.

В Соединенных Штатах даты пишутся ММ-ДД-ГГГГ. (02-10-2015 = 10 февраля 2015 г.) Но в Европе и многих других местах даты пишутся ДД-ММ-ГГГГ. (02-10-2015 = 2 октября 2015 г. или 2 октября 2015 г.).

В то время как Magento базируется в США, большая часть разработки была сделана программистами в Украине. 

Мы исправили эту ошибку с помощью бесплатного расширения Magento (чтобы вам не приходилось изменять код ядра Magento). Мы разместили его на нашем сайте для бесплатной загрузки: http://www.CustomerParadigm.com/download/Magento-Date-Switch-Fix-Extension.zip

Я рассказал об этом более подробно в нашем блоге здесь: http://www.customerparadigm.com/magento-bug-magento-customer-create-date-juxtaposition/

CE 1.9 исправил ошибку в CE 1.8.1 Ниже приведен diff: