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.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
1. SELECT id FROM identifikatory WHERE nazev = 'nazev'; // pokud predchozi select vrati id, pak 2. INSERT INTO tabulka VALUES (id, .....)Tyto operace provádím v transakci s úrovní REPEATABLE READ, ale nemyslím si, že by samotná transakce ochránila bod 2 před tím, aby někdo mezitím smazal dané id. V tabulce tabulka je totiž id jako cizí klíč na tabulku identifikatory, takže ve druhém kroku potřebuju, aby id existovalo. Jakým způsobem mohu zajistit, aby id určitě existovalo ve 2. kroku?
INSERT INTO tabulka SELECT id, ..... FROM identifikatory WHERE nazev='nazev' LIMIT 1;Pokud
nazev
nebude existovat, nový záznam se nevloží.
identifikatory
indexovánu podle sloupce nazev
.
Tu časovou náročnost jsem nedávno měřil. Není to tak zlé, jak se povídá. Navíc všech 1000 záznamů můžeš vložit jedním insertem, takže to bude i rychlé.
protože při repeatable reads transakce díky race condition může selhat i z jiných v podstatě neodstranitelných důvodů)Jakých třeba? Opakování transakcí nikde implementováno nemám. Vyzkoušel jsem, že transakce v REPEATABLE READS může selhat takto:
sezení 2: START TRANSACTION SELECT id FROM hlavni_tabulka WHERE id = 2; sezení 1: DELETE FROM hlavni_tabulka WHERE id = 2; sezení 2: INSERT INTO vedlejsi_tabulka (id, ...) VALUES (2, ....); // selže kvůli cizímu klíči id tabulky hlavni_tabulka tzn. ačkoliv mi v tomto boděO jiných důvodech proč by mělo REPEATABLE READS selhat nevím. Souběh už by měla mít databáze vyřešený ne?
dotaz "SELECT id FROM hlavni_tabulka WHERE id = 2" vrací hodnotu, fyzicky už to tam neexistuje a foreign key zajímá
jen poslední verze. Tohle nevím jak vyřešit kromě izolace SERIALIZABLE, která by měla zamknout čtené řádky, ale to bohužel (jak jsem dnes zjistil) nemohu udělat, protože potřebuju,
aby ostatní sezení měla k dispozici RW přístup k řádkům hlavní tabulky během transakce (která může trvat i několik desítek minut - miliony řádků).
CREATE TABLE a (a integer) engine innodb; INSERT INTO a values (1);když spustím následující řádky synchronně ve dvou transakcích (vždy stejný řádek v jedné a pak v druhé), tak mi ta druhá nezařve, i když by měla (a např. v postgresql zařve) a normálně počká na commit první transakce a pak zahlásí nula modifikovaných řádek.
set session transaction isolation level repeatable read ; BEGIN; SELECT * FROM a; UPDATE a set a=2 /*v druhé =3*/ where a=1; COMMITPřitom další SELECT * FROM a; furt tvrdí, že tam v té tabulce je jednička. Tomu tedy rozhodně neříkám repeatable reads, tomu říkám paskvil. --- Nicméně obecně: pokud chceš mít dlouhé transakce, během kterých ostatní transakce mají RW přístup, nemůžeš zajistit konzistenci. To prostě z principu nelze. Buď máš konzistentní čtení/zápis, pak ale když se sejdou dvě transakce nad stejnými daty, ne vždy jdou uspořádat a tedy je potřeba někdy jednu zrušit a pak zavolat znova. To u dlouhé transakce je blbina, pak ji musíš rozsekat na krátké transakce. Anebo se vykašleš na konzistenci. Zajistit obojí prostě nejde - když té dlouhé transakci změní něco krátká transakce pod rukama, tak to prostě "automaticky" vyřešit nejde.
identifikatory
byla stabilní a potřeboval bys větší výkon databáze, zvaž její odstranění. Místo cizího klíče pak použiješ datový typ ENUM. Databáze s ENUM pracuje o něco rychleji a hlavně je s ním mnohem pohodlnější práce. Vně se chová jako varchar, ale uvnitř je to jen jednobajtový (příp. dvoubajtový) identifikátor.
SELECT id FROM identifikatory WHERE nazev = 'nazev' FOR UPDATE;
Tiskni Sdílej: