Konference LinuxDays 2023 proběhne již tento víkend 7. a 8. října v prostorách Fakulty informačních technologií Českého vysokého učení v Praze (FIT ČVUT). Na programu je spousta zajímavých přednášek a workshopů.
Netflix v pátek 29. září odeslal poslední film na DVD (YouTube). Společnost dnes známá jako streamovací služba začala před 25 lety jako půjčovna filmů na DVD. Zákazník si DVD objednal na webových stránkách, odesláno mu ale bylo klasickou poštou. Po zhlédnutí jej vložil do obálky a poslal zpět.
Zero Day Initiative zveřejnila informace o 6 bezpečnostních chybách (1, 2, 3, 4, 5, 6) v MTA Exim. Nejvážnější z nich CVE-2023-42115 má CVSS 9.8. Na opravě chyb se pracuje.
Knihovna libvpx byla vydána ve verzi 1.13.1. Řešena je kritická bezpečnostní chyba CVE-2023-5217 (heap buffer overflow in vp8 encoding). Chyba je již opravena také v Chrome / Chromium 117.0.5938.132 a Firefoxu 118.0.1.
Balíček kmod s nástroji pro práci s linuxovými moduly byl vydán ve verzi 31. Nově umí modprobe zavést modul nacházející se v libovolném adresáři (# modprobe ./drivers/gpu/drm/i915/i915.ko).
Adventura Trüberbrook je na portále GOG.com zdarma, akce trvá do 2. října.
Sound Open Firmware, projekt Linux Foundation, open source audio DSP firmware a SDK, byl vydán ve verzi 2.7.0. Z novinek lze vypíchnout podporu platformy AMD Van Gogh.
Richard Stallman v den oslav 40. výročí GNU oznámil, že má rakovinu (YouTube).
DIY trackball Ploopy má novou variantu Adept, na rozdíl od předchozích používá 44mm kouli, má symetrický tvar a šest tlačítek, snímač zůstává PMW-3360, novinkou je použití Raspberry Pi Pico, na kterém běží firmware QMK s podporou grafické konfigurační aplikace VIA. Předobjednávky jsou otevřeny za ceny 80-105 CAD.
Probíhá Meta Connect 2023. Společnost Meta představuje své novinky v oblasti AI a virtuální, smíšené a rozšířené reality. Představeny byly nové chytré brýle Ray-Ban | Meta a headset Meta Quest 3.
A/ SELECT id, name FROM t WHERE id = 8 AND name != "Pepa"; B/ SELECT id, name FROM t WHERE id = 8 AND name != "Pepa"; A/ UPDATE t SET name = "Pepa" WHERE id = 8; B/ UPDATE t SET name = "Josef" WHERE id = 8;Ve výsledku chceme, aby v tabulce byla uložena hodnota "Pepa", a ten "Josef" se zamítl. Zatímco normálně to prostě přepíše a nikdo se nic nedozví. A to není dobře. Protože dotyčný tvrdil, že to lze řešit a jako příklad uvedl Wikipedii a Hibernate, zkusil jsem si o tom něco nastudovat. Třeba u Hibernate jsem našel, že si nějak kontroluje verzi dat, a při update kontroluje, zda ukládá do stejné verze. Vypadalo to zajímavě. Existuje nějaký osvědčený způsob? Co by ste doporučili?
FOR UPDATE
.
UPDATE platy SET plat = plat * 1.1, verze = verze + 1 WHERE oddeleni = 1
Místo (podle mne nebezpečného) číslování verzí raději volím timestamp.Vidiš to. A já bych za nebezpečné považoval spíše ten timestamp. (Už se mi stalo, že v daném okamžiku se vygenerovali stejné konfliktní timestampy.)
UPDATE t SET name = "Pepa", version=version+1 WHERE id = 8 AND version=1;ale to je možná jen má neznalost, a záleží, zda je to takto pro tu kterou databázi atomický příkaz. Až po odeslání toho dotazu jsem si uvědomil, že teprve v případě vícero příkazů v jedné transakci to začne být sranda. Takže beru zpět.
Pokud by se takhle jednoduchý UPDATE neprovedl atomicky, byla by ta databáze opravdu divná.
Proč by měla být divná? Pokud chci atomicitu, mám prostředek, jak ji zajistit (transakce). Pokud ho nepoužiju, pak ji zajištěnou nemám; spoléhat na to, že ten či onen dotaz je tak jednoduchý, že prostě musí být atomický, je holý nesmysl.
Obecně mne nepřestává fascinovat, jak krkolomné konstrukce jsou lidé schopni vymyslet, aby se nemuseli naučit používat transakce.
version
ve výrazu version + 1
bude mít stejnou hodnotu, jako version
v podmínce WHERE
, ani nic o tom, že v okamžiku zápisu té hodnoty version
bude mít kteroukoli z předchozích dvou hodnot.
BEGIN UPDATE table SET version = version + 1 WHERE version = 1 AND id = 1; -- version == 1, podmínka WHERE splněna BEGIN UPDATE table SET version = 2 WHERE id = 1; COMMIT; -- version == 2, hodnota version + 1 je 3 BEGIN UPDATE table SET version = 4 WHERE id = 1; COMMIT; -- version == 4 COMMIT; -- version přepsáno ze 4 na 3Tohle je atomická transakce, přesto se v průběhu UPDATE dvakrát změnila hodnota
version
.
READ COMMITTED
. Nejpodstatnější je ta změna před zápisem, a k té může dojít ve všech případech mimo SERIALIZABLE. V případě toho zápisu záleží především na tom, jak je udělané zamykání, a o tom transakce nic neříkají (respektive jediná úroveň, která v tomto smyslu něco zaručuje, je SERIALIZABLE).
Podstatné je to, že úplné oddělení transakcí zajišťuje jen úroveň SERIALIZABLE, a že nižší úrovně nezajišťují vše, co lidé od transakcí intuitivně očekávají. Ale ne všude se SERIALIZABLE používá, takže pak je potřeba zjišťovat, co mi zvolená úroveň oddělení transakcí doopravdy zajišťuje, resp. jestli daný požadavek zajišťuje např. způsob implementace zamykání v dané databázi.
version
bude v té transakci stále stejné. Ale pořád to neřeší problém, že je potřeba aktualizovaná data zamknout. V případě aktualizace jednoho nezávislého řádku tabulky se o ten zámek postará databáze (ale je to záležitost konkrétní implementace, repeatable read transakce nic takového nevyžaduje). Jenže pokud ten update bude záviset na dalších datech, databáze o tom nemusí vědět, nezamkne vše potřebné a stále může dojít k tomu nechtěnému přepisu dat. Repeatable read přitom situaci paradoxně zhoršuje, protože zvyšuje pravděpodobnost, že se bude pracovat se starými daty.
UPDATE t SET name = "Pepa", version=version+1 WHERE id = 8 AND version=1;Ale musíš si odchytit, zda se ten dotaz provedl či ne. Případně je možnost si na to napsat assertovací funkci. Něco jako:
UPDATE t SET name = "Pepa", version=assert_version(version, 1) WHERE id = 8;Ale to je fakt jen taková vychytávka, aby se ti jednotně vraceli výjimky.
Vidím jeden problém s verziovaním, ktoré tu navrhujú kolegovia. Keď druhý UPDATE neprebehne, tak čo potom spraví používateľ? Otvorí si aktuálny záznam a začne svoje zmeny písať znova? Čo keď robí zložitejšie zmeny a kým ich dokončí tak mu to zase niekto updatne? Alebo čo keď bol so zákazníkom na telefóne, zmeny mu zákazník diktoval a sám si ich nepamätá?Mrkni jak to dělá Wikipedia. Minimálně pro ilustraci.
Co databazi poslu, to tam mam. Co vic bych od ni chtel? Atomicitu zarucim na urovni DB pomoci transakce, ale bez atomicity na urovni aplikace je to k nicemu.
Staci treba hlidat zmenu (verzovanim) a v pripade zmeny upozornit uzivatele, pripadne radky v tabulce zamykat.
Ja treba pro realtimovost aplikace pouzivam zvlastni sitovy synchronizacni server, ktery ohlasuje klientum, jaka sdilena data si maji nacist, pripadne co maji udelat. Tim se tomuhle aktivne vyhnu, presto kontroluji verzi dat.
Tiskni
Sdílej: