Pourquoi create_at (table customer_entity) est-il configuré pour changer lors de la mise à jour?

Lorsque l'on regarde la structure de la customer_entitytable, j'ai remarqué le created_atchamp a cet attribut: on update CURRENT_TIMESTAMP. Ainsi, chaque fois que la ligne est mise à jour, l' created_athorodatage change.

Il semble que cet attribut devrait exister sur le updated_atterrain, pas sur le created_atterrain. Je sais qu'il est rare que ce tableau soit directement modifié en raison de la structure de l'EAV, mais il semble toujours mal de jamais modifier le created_atchamp.

Y a-t-il une raison à cette structure de table, ou s'agit-il simplement d'un bug?

Edit: J'ai trouvé un rapport de bogue confirmé de Magento pour cela. Numéro # 27944. Malheureusement, vous devez vous connecter pour le voir. http://www.magentocommerce.com/bug-tracking/issue?issue=13882

Voici ce que j'ai trouvé. Le problème n'apparaît que sur Magento CE 1.6+ (et les versions EE correspondantes). C'est à cause des nouveaux scripts d'installation / mise à niveau utilisant DDL en combinaison avec mysql.
Dans les versions antérieures à 1.6, voici à quoi ressemblaient les colonnes created_atet 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', 

Dans 1.6+, le ddl ressemble à ceci:

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

et génère:

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

La différence est que la defaultvaleur est manquante.
Et, comme décrit ici ,

Avec ni DEFAULT CURRENT_TIMESTAMP ni ON UPDATE CURRENT_TIMESTAMP, cela revient à spécifier à la fois DEFAULT CURRENT_TIMESTAMP et ON UPDATE CURRENT_TIMESTAMP.

Et puisque MySQL n'autorise qu'une seule colonne d'horodatage avec CURRENT_TIMESTAMPcomme valeur par défaut ou pour on update, la created_atcolonne se retrouve avec ceci.

Il s'agit définitivement d'un bug Magento.

Tout d'abord, lisez la réponse de Marius pour voir ce qui se passe dans la base de données.

Je voulais juste mentionner que la plupart des développeurs ne rencontreront pas ce problème si leur modèle s'étend correctement Mage_Core_Model_Abstract. La pile ressemble à ceci:

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

Cela fait ce qui suit:

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

Notez simplement que cela peut avoir des problèmes pour certains paramètres régionaux dans CE> = 1.8.x et EE> = 1.13.x.

Nous aussi, nous avons trouvé ce bogue et pensons qu'il est basé sur la différence entre l'encodage de date américain et européen.

Aux États-Unis, les dates sont écrites MM-DD-YYYY. (02-10-2015 = 10 février 2015). Mais en Europe et dans bien d'autres endroits, les dates sont écrites DD-MM-YYYY. (02-10-2015 = 2 octobre 2015, ou 2 octobre 2015).

Alors que Magento est basé aux États-Unis, une grande partie du développement a été réalisée par des programmeurs en Ukraine. 

Nous avons corrigé ce bogue avec une extension Magento gratuite (afin que vous n'ayez pas à changer de code Magento Core). Nous l'avons mis sur notre site en téléchargement gratuit: http://www.CustomerParadigm.com/download/Magento-Date-Switch-Fix-Extension.zip

J'ai couvert cela plus en détail sur notre blog ici: http://www.customerparadigm.com/magento-bug-magento-customer-create-date-juxtaposition/

ce 1.9 a corrigé le bogue dans ce 1.8.1 Voici le diff: