V Londýně probíhá dvoudenní Ubuntu Summit 25.10. Na programu je řada zajímavých přednášek. Zhlédnout je lze také na YouTube (23. 10. a 24. 10.).
Gemini CLI umožňuje používání AI Gemini přímo v terminálu. Vydána byla verze 0.10.0.
Konference OpenAlt 2025 proběhne již příští víkend 1. a 2. listopadu v Brně. Nabídne přibližně 80 přednášek a workshopů rozdělených do 7 tematických tracků. Program se může ještě mírně měnit až do samotné konference, a to s ohledem na opožděné úpravy abstraktů i případné podzimní virózy. Díky partnerům je vstup na konferenci zdarma. Registrace není nutná. Vyplnění formuláře však pomůže s lepším plánováním dalších ročníků konference.
Samsung představil headset Galaxy XR se 4K Micro-OLED displeji, procesorem Snapdragon XR2+ Gen 2, 16 GB RAM, 256 GB úložištěm, operačním systémem Android XR a Gemini AI.
Před konferencí Next.js Conf 2025 bylo oznámeno vydání nové verze 16 open source frameworku Next.js (Wikipedie) pro psaní webových aplikací v Reactu. Přehled novinek v příspěvku na blogu.
Sovereign Tech Fund oznámil finanční podporu následujících open source projektů: Scala, SDCC, Let's Encrypt, Servo, chatmail, Drupal, Fedify, openprinting, PHP, Apache Arrow, OpenSSL, R Project, Open Web Docs, conda, systemd a phpseclib.
Bylo vydáno OpenBSD 7.8. S předběžnou podporou Raspberry Pi 5. Opět bez písničky.
Valkey (Wikipedie) byl vydán v nové major verzi 9.0. Valkey je fork Redisu.
Byly publikovány informace o kritické zranitelnosti v knihovně pro Rust async-tar a jejích forcích tokio-tar, krata-tokio-tar a astral-tokio-tar. Jedná se o zranitelnost CVE-2025-62518 s CVSS 8.1. Nálezci je pojmenovali TARmageddon.
AlmaLinux přinese s verzí 10.1 podporu btrfs. XFS bude stále jako výchozí filesystém, ale instalátor nabídne i btrfs. Více informací naleznete v oficiálním oznámení.
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: