Dotaz: MySQL a záhadně propojené sloupce

[Barbucha.eu]

Mám tabulku a v ní se mi děje cosi, čemuž moc nerozumím.

create table logins
(
	logId		int unsigned		not null primary key auto_increment,
	userId		tinyint unsigned	not null, /* FK */
	login		timestamp		not null,
	logout		timestamp,
	hostId		smallint unsigned	not null, /* FK */
	expired		bit			not null default 1,
	foreign key (userId) references users(userId) on delete cascade,
	foreign key (hostId) references hosts(hostId) on delete cascade
) engine=innodb;

V té tabulce když provedu změnu dvou buněk v jednom řádku, tak se v onom řádku změní buňky tři. Myslel jsem si, že chyba je někde v aplikaci, nebo uložené proceduře, protože jak je už z tohoto výpisu zřejmé, doba přihlášení a odhlášení je vždy stejná. Tak jsem poslední hodnotu, která ještě nebyla nastavována, upravil ručně.

mysql> select * from logins;
+-------+--------+---------------------+---------------------+--------+---------+
| logId | userId | login               | logout              | hostId | expired |
+-------+--------+---------------------+---------------------+--------+---------+
|     1 |      3 | 2008-06-01 17:20:02 | 2008-06-01 17:20:02 |      1 |         |
|     2 |      3 | 2008-06-01 17:21:25 | 2008-06-01 17:21:25 |      1 |         |
|     3 |      1 | 2008-06-01 17:22:12 | 2008-06-01 17:22:12 |      1 |         |
|     4 |      2 | 2008-06-01 17:26:12 | 0000-00-00 00:00:00 |      1 |       1 |
+-------+--------+---------------------+---------------------+--------+---------+
4 rows in set (0.00 sec)

Spustil jsem samotný příkaz update zkopírovaný z uložené procedury.

mysql> update logins set expired=0,logout=current_timestamp where logId=4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

Výsledek mě dosti zarazil. Posuďte sami.

mysql> select * from logins;
+-------+--------+---------------------+---------------------+--------+---------+
| logId | userId | login               | logout              | hostId | expired |
+-------+--------+---------------------+---------------------+--------+---------+
|     1 |      3 | 2008-06-01 17:20:02 | 2008-06-01 17:20:02 |      1 |         |
|     2 |      3 | 2008-06-01 17:21:25 | 2008-06-01 17:21:25 |      1 |         |
|     3 |      1 | 2008-06-01 17:22:12 | 2008-06-01 17:22:12 |      1 |         |
|     4 |      2 | 2008-06-01 17:26:25 | 2008-06-01 17:26:25 |      1 |         |
+-------+--------+---------------------+---------------------+--------+---------+
4 rows in set (0.00 sec)

Přestože nad tabulkou není nikde vytvářen žádný trigger a v příkazu update se při odhlášení nastavují jen sloupce expired a logout, změní se i hodnota ve sloupci login. Nedovedu si takové záhadné chování MySQL-serveru vysvětlit. Čím to může být, že při vkládání se sloupce chovají normálně a při úpravě se chovají, jakoby byly jen jeden?

---

---

Odpovědi

[Filip Jirsák]

Zkusil bych si tu samou tabulku (bez FK) vytvořit na nějaké úplně čisté databázia porovnat, zda se to bude chovat stejně. Ať víte, kterým směrem pátrat – zda je to problém právě té jedné instance vaší databáze, nebo zda se tak chová MySQL vždy.

[Dalibor Smolík]

Zkusil jsem si takovou tabulku vytvořit, změny se projevují podobně (změna v obou polích při zadání změn jen v jednom z nich) - není to právě vlastnost pole typu timestamp?

[Barbucha.eu]

Strucne receno, sloupec typu TIMESTAMP se updatuje sam a to na hodnotu kdy bylo naposledy s radkem hybano, proste takove automaticke datum posledni zmeny - pokud mu neni prirazena explicitne jina hodnota (coz je feature a ne bug :)

Presne je to chovani popsano v manualu: http://dev.mysql.com/doc/refman/5.0/en/timestamp.html

Ve starsich verzich (4.1 a starsi) se to chovani pak jetse trochu lisi od nejnovejsi.

[dustin]

Přesně tak. Autor asi chtěl použít typ DATETIME.