Patrząc na strukturę customer_entity
tabeli, zauważyłem, że created_at
pole ma ten atrybut: on update CURRENT_TIMESTAMP
. Dlatego przy każdej aktualizacji wiersza created_at
zmienia się znacznik czasu.
Wygląda na to, że ten atrybut powinien istnieć na updated_at
polu, a nie na created_at
polu. 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_at
pola.
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
magento-1.7
Ryre
źródło
źródło
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
. Mogą być też inni. W pewnym momencie straciłem zainteresowanie, szukając ich.sales_flat_quote
Najpierw zauważyłem , a potem sprawdziłemcustomer_entity
. Właśnie to zauważyliśmy, ponieważ niektóre z naszych raportów nie miały żadnego sensu. Czy to naprawdę może być błąd?Odpowiedzi:
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_at
iupdated_at
:W wersji 1.6+ ddl wygląda następująco:
i generuje:
Różnica polega na tym, że
default
brakuje wartości.I, jak opisano tutaj ,
A ponieważ MySQL dopuszcza tylko jedną kolumnę ze znacznikiem czasu
CURRENT_TIMESTAMP
jako domyślną lub dlaon update
,created_at
kolumna kończy się w ten sposób.To zdecydowanie błąd Magento.
źródło
created_at
znacznik czasu NIE NULL DOMYŚLNY CURRENT_TIMESTAMP W AKTUALIZACJI CURRENT_TIMESTAMP KOMENTARZ „Utworzono o”. W informacjach o wersji wspomniano, że „data„ klienta od ”jest poprawna”.`created_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'Created At'
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:Your_Model::save
połączeniaMage_Core_Model_Abstract::save
połączeniaMage_Eav_Model_Entity_Abstract::save
połączeniaMage_Eav_Model_Entity_Abstract::_beforeSave
połączeniaMage_Eav_Model_Entity_Abstract::walkAttributes
połączeniaMage_Eav_Model_Entity_Attribute_Backend_Time_Created::beforeSave
Robi to:
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.
źródło
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/
źródło
ce 1.9 naprawiłem błąd w ce 1.8.1 Poniżej znajduje się różnica:
źródło