Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
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: 0Vý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?
Řešení dotazu:
Tiskni Sdílej: