क्यों बनाया गया है अद्यतन पर बदलने के लिए सेट (customer_entity तालिका)?

Question

जब customer_entityतालिका की संरचना को देखते हुए , मैंने देखा कि created_atक्षेत्र में यह विशेषता है on update CURRENT_TIMESTAMP:। इसलिए हर बार जब पंक्ति को अपडेट किया जाता है, created_atटाइमस्टैम्प बदल जाता है।

ऐसा लगता है कि यह विशेषता updated_atफ़ील्ड पर मौजूद होनी चाहिए , न कि created_atफ़ील्ड पर। मुझे पता है कि यह दुर्लभ है कि इस तालिका को ईएवी संरचना के कारण सीधे संशोधित किया गया है, लेकिन अभी भी इस created_atक्षेत्र को संशोधित करना गलत है ।

क्या इस तालिका संरचना का कोई कारण है, या यह सिर्फ एक बग है?

संपादित करें: मुझे इसके लिए Magento की एक बग रिपोर्ट की पुष्टि मिली। अंक # 27944 दुर्भाग्य से, आपको इसे देखने के लिए लॉग इन करना होगा। http://www.magentocommerce.com/bug-tracking/issue?issue=13882

Comments

अच्छा प्रश्न। मैं जोड़ सकते हैं कि इन तालिकाओं एक ही स्थिति में हैं: cron_schedule, api_user, admin_user, customer_entity_address, downloadable_link_purchased, downloadable_link_purchased_item, index_event, eav_entity log_customer, sales_flat_quote_address, sales_flat_quote, sales_flat_quote_address_item, sales_flat_quote_payment, sales_flat_quote_shipping_rate, sales_recurring_profile। अन्य भी हो सकते हैं। मैंने एक बिंदु पर उनकी रुचि खो दी, जबकि उन्हें खोज रहा था।

— मेरियस

मैंने sales_flat_quoteपहले गौर किया , फिर जाँच की customer_entity। हमने इसे केवल इसलिए देखा क्योंकि हमारी कुछ रिपोर्टें कोई मतलब नहीं थीं। क्या यह वास्तव में बग हो सकता है?

— रायरे

मेरा मानना ​​है कि यह सिर्फ एक बग है।

— Dmytro Zavalkin

मेरे पास कोई भी तरीका है जिससे हम उसके आसपास काम कर सकें? क्षमा करें, मैं एक नौसिखिया हूँ और मैं उसी मुद्दे का सामना कर रहा हूँ जब से मैं 1.7.0.2 से अपग्रेड किया गया था। आशा है कि आप मदद कर सकते हैं !! धन्यवाद जिनल

— Jinal

@ जीनल, मेरा सबसे अच्छा विकल्प mysql के माध्यम से परिवर्तन करना है। अधिक विवरण के लिए मारियस के उत्तर की जाँच करें, और पहले अपने डेटाबेस का बैकअप लेना सुनिश्चित करें!

— रियरे

Answer 1

जो मुझे मिला वह यहां है। यह समस्या केवल Magento CE 1.6+ (और EE संस्करणों के मिलान) पर दिखाई देती है। यह mysql के साथ संयोजन में DDL का उपयोग करके नई इंस्टॉल / अपग्रेड स्क्रिप्ट के कारण है।
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 और न ही UPDATE CURRENT_TIMESTAMP पर, यह DEFAULT CURRENT_TIMESTAMP और OND दोनों CURRENT_TIMESTAMP को निर्दिष्ट करने के समान है।

और चूंकि MySQL CURRENT_TIMESTAMPडिफ़ॉल्ट रूप से या इसके साथ केवल एक टाइमस्टैम्प कॉलम की अनुमति देता है on update, created_atकॉलम इस तरह से समाप्त होता है।

यह निश्चित रूप से एक Magento बग है।

Comments

इस पर magento से कोई अद्यतन किया गया है? ऐसा लगता है कि बग अभी भी नए राज्य में है।

— लौरा

@ लौरा, जवाब में बग ट्रैकिंग लिंक अभी भी खुले (लगभग 2 साल अब!) के रूप में दिखाता है।

— रायरे

मैगेंटो 1.9 में, बनाया_ट कॉलम कहता है: created_atटाइमस्टैम्प नॉट नाउल डिफॉल्ट CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'Created At'। और जारी नोटों में, यह उल्लेख किया गया है कि "तारीख से ग्राहक" सही है।

— मगेप्सिचियो

ईई के लिए यह पहले से संस्करण 1.6 को प्रभावित कर रहा है, मेरे पास ईई 1.13 है और यह इस तरह दिखता है: `created_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'Created At'

— doc_id

Answer 2

सबसे पहले, डेटाबेस में क्या हो रहा है यह देखने के लिए मारियस का जवाब पढ़ें।

मैं सिर्फ यह उल्लेख करना चाहता था कि अधिकांश डेवलपर्स इस समस्या में नहीं चलेंगे यदि उनका मॉडल ठीक से विस्तारित हो 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 दोनों में कुछ स्थानों की समस्या हो सकती है।

Answer 3

हम भी इस बग को ढूंढते हैं, और सोचते हैं कि यह अमेरिका और यूरोपीय तारीख एन्कोडिंग के बीच के अंतर पर आधारित है।

संयुक्त राज्य अमेरिका में, तारीखों को MM-DD-YYYY लिखा जाता है। (02-10-2015 = 10 फरवरी, 2015)। लेकिन यूरोप और कई अन्य स्थानों में, तिथियां डीडी-एमएम-वाईवाईवाई लिखी जाती हैं। (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/

Comments

ब्लॉग पोस्ट और मॉड्यूल सिर्फ मेरी एसई पोस्ट से यहां खींचे गए

— टायलर वी।

Answer 4

सी। ई। 1.9 में बग को ठीक करना है।

Comments

यहां नया कोड इस समस्या के लिए ठीक नहीं है। यह सिर्फ "DDDD-DD-DD-DD DD: DD: DD" प्रारूप को मान्य करता है, या शून्य देता है। वह नल अभी भी डेटाबेस से टकराएगा और जो भी कॉलम डिफ़ॉल्ट मान है वह बन जाएगा।

— टायलर वी।