|
Promena prikaza TIMESTAMP polja u MySQL
Danas sam, na tezi nacin, naucio najnoviji "feature" MySQL.
Citat:
Dakle, svi koji koriste timestamp(14) i ocekuju vrednost polja: YYYYMMDDHHIISS mogu da se oproste od toga pošto se vraća klasičan DATETIME. Ja iskreno ne znam razlog ovakvoj promeni. Predlažem workaround: 1. Definisate problematično polje kao CHAR(14) ali onda se gubi funkcionalnost TIMESTAMP 2. Parsovati vrednost kao DATETIME 3. Ubiti nekoga iz MySQL ko je ovu promenu osmislio 4. Ubiti mene pošto sam na server stavio MySQL 4.1.14 a da nisam ni znao za ovo. |
Jedan od razloga zašto uvek, ali uvek čitam changelog - još otkako sam imao "veselu" situaciju sa MS DAO API-em i Access-om 2000.
|
Pa ti si naučno-istraživački radnik a mi smo samo miševi... :)
Ma čitam i ja često, ali ne uvek... nekada su me kolege na poslu zvale "mr. readme" pošto sam uvek čitao takve stvari... ali eto, trenutak nepažnje... Hteo sam da učinim, na serveru je trenutno PHP 5.1.1 i mysql 4.1.14, apache 2.0.52, medjutim napravio sam "medvedju uslugu"... sada znam zasto su vecina hostova toliko intertni kada treba da se stavi nova verzija necega na server. |
<post offtopic="true">
Citat:
</post> |
Citat:
inace meni je taj njihov bivsi format timestampa bio skroz glupav, nekako mi je timestamp logicno da bude vrednost u sekundama, kao unix timestamp...uglavnom je to ono sto ti treba, ili datum da ga prikazes ili sekunde da racunas nesto sa njima, a onaj YYYYMMDD format mi je bio skroz neupotrebljiv... mada jeste jako glupo sto su tek tako promenili format, bolje da su uveli novi tip polja...ali jebga, sta je tu je, mozemo samo da pisemo svom kongresmenu :/ |
Primeri da se razbija backward compatibility su sve češći kad radite sa LAMPom. PHP ga je razbio prvo sa peticom, a kasnije i sa famoznim Only variables can be passed by reference. Nisam isto očekivao i od MySQLa. Oni su mi uvek delovali kao pametni momci :)
Ne govorom direktno o promenama i razlozima zašto su napravljene (promene su uvek na bolje sa debelim razlozima), već o načinu na koji su dodate (mi to lepo dodamo, a vi se dalje snalazite). Pitam se samo da li bi neki tamo Oracle ili Microsoft ovo smeo da dozvoli sebi? Najverovatnije bi, ali po koju cenu... A najtužnije je što hostovi ne upgraduju jer nisu načisto šta će se desiti (da li će doći do situacije navedene gore). Lakše im je da ostave po starom ili da koriste granu gde nije došlo do "revolucionarnih" promena. PS: Drago mi je zbog sveže platforme na Host011. Otvarate svet pun novih mogućnosti domaćim developerima :) |
Za ovaj novi "feature" timestamp polja znam već neko vreme, valjda zato što praktikujem da pročitam svako novo izdanje MySQL-a (by Paul Dubois) :)
Ova konkretna izmena je imho krajnje nelogična, jer gotovo i da nema razlike između datetime i timestamp polja, tj.: Kôd:
foo timestamp <=> foo datetime default CURRENT_TIMESTAMP |
Citat:
meni na 4.1.9 ne dozvoljava da setujem default za datetime da bude CURRENT_TIMESTAMP ? Kaze da je to invalid default value (myISAM tabela) od koje verzije su to podrzali? |
Od nijedne :) To sam stavio više ilustracije radi, tj. da je timestamp polje (od MySQL >= 4.1) istog oblika kao datetime s tim što je default vrednost CURRENT_TIMESTAMP (tj. prilikom update-a po defaultu se setuje na trenutni timestamp).
Inače, za timestamp je moguće to definisati kao recimo sa: Kôd:
foo timestamp on update CURRENT_TIMESTAMP default CURRENT_TIMESTAMP |
a tooo...:)
ma dobro za timestamp je to default ponasanje, sem kad ih je vise u istoj tabeli... ali sam ja pogresno shvatio kad si rekao da su timestamp i datetime postali skoro isti...posto je ocigledno timestamp i dalje neophodan ako zelis da ti se vreme poslednje izmene automatski azurira, datetime to ne ume... |
| Vreme je GMT +2. Trenutno vreme je 22:20. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.