Чому для оновлення встановлюється зміна create_at (таблиця_спроможність клієнта)?

При погляді на структуру 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, ані ОНОВЛЕНО CURRENT_TIMESTAMP, це те саме, що вказати як DEFAULT CURRENT_TIMESTAMP, так і НА 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.

Ми теж знайшли цю помилку і думаємо, що вона заснована на різниці між кодуванням дат США та Європи.

У Сполучених Штатах дати записуються MM-DD-YYYY. (10.10.2015 = 10 лютого 2015 р.). Але в Європі та багатьох інших місцях дати записуються DD-MM-YYYY. (02-10-2015 = 2 жовтня 2015 або 2 жовтня 2015).

Незважаючи на те, що Magento базується в США, значна частина розробок була здійснена програмістами в Україні. 

Ми виправили цю помилку за допомогою безкоштовного розширення Magento (так що вам не доведеться змінювати будь-який Magento Core Code). Ми розмістили його на нашому сайті як безкоштовне завантаження: 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 нижче: