Google Chrome 142 byl prohlášen za stabilní. Nejnovější stabilní verze 142.0.7444.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 20 bezpečnostních chyb. Za nejvážnější z nich bylo vyplaceno 50 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
Pro moddery Minecraftu: Java edice Minecraftu bude bez obfuskace.
Národní identitní autorita, tedy NIA ID, MeG a eOP jsou nedostupné. Na nápravě se pracuje [𝕏].
Americký výrobce čipů Nvidia se stal první firmou na světě, jejíž tržní hodnota dosáhla pěti bilionů USD (104,5 bilionu Kč). Nvidia stojí v čele světového trhu s čipy pro umělou inteligenci (AI) a výrazně těží z prudkého růstu zájmu o tuto technologii. Nvidia již byla první firmou, která překonala hranici čtyř bilionů USD, a to letos v červenci.
Po Canonicalu a SUSE oznámil také Red Hat, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie).
TrueNAS (Wikipedie), tj. open source storage platforma postavená na Linuxu, byl vydán ve verzi 25.10 Goldeye. Přináší NVMe over Fabric (NVMe-oF) nebo OpenZFS 2.3.4.
Byla vydána OpenIndiana 2025.10. Unixový operační systém OpenIndiana (Wikipedie) vychází z OpenSolarisu (Wikipedie).
České základní a střední školy čelí alarmujícímu stavu kybernetické bezpečnosti. Až 89 % identifikovaných zranitelností v IT infrastruktuře vzdělávacích institucí dosahuje kritické úrovně, což znamená, že útočníci mohou vzdáleně převzít kontrolu nad klíčovými systémy. Školy navíc často provozují zastaralé technologie, i roky nechávají zařízení bez potřebných aktualizací softwaru a používají k nim pouze výchozí, všeobecně známá
… více »Během tradiční ceremonie k oslavě Dne vzniku samostatného československého státu (28. října) byl vyznamenán medailí Za zásluhy (o stát v oblasti hospodářské) vývojář 3D tiskáren Josef Průša. Letos byly uděleny pouze dvě medaile Za zásluhy o stát v oblasti hospodářské, druhou dostal informatik a manažer Ondřej Felix, který se zabývá digitalizací státní správy.
Tor Browser, tj. fork webového prohlížeče Mozilla Firefox s integrovaným klientem sítě Tor přednastavený tak, aby přes tuto síť bezpečně komunikoval, byl vydán ve verzi 15.0. Postaven je na Firefoxu ESR 140.
Takze me zajima cizi nazor.
do té doby, než mění nějaký společný záznamo prispevek vyse
obě nastaví aktuální revizi na false
Stačí?
- Začíná 1. transakce (1)
- (1) TRANSACTION BEGIN
- (1) UPDATE SET aktualni = false WHERE aktualni = true;
- (1) -- tabulka je prázdná, tj. WHERE není splněno pro žádný řádek, žádný řádek se nazamyká
- (1) INSERT INTO (aktualni) VALUES (true);
- Začíná 2. transakce (2), 1. stále trvá
- (2) BEGIN TRANSACTION
- (2) UPDATE SET aktualni = false WHERE aktualni = true;
- (2) -- 1. transakce stále není potvrzená, a nemá zamčený žádný řádek, takže UPDATE normálně proběhne nad prázdnou tabulkou, tj. žádný řádek se nezamyká
- (1) TRANSACTION COMMIT
- (1) -- do tabulky se zapisuje 1. řádek s aktualni=true
- (2) INSERT INTO (aktualni) VALUES (true);
- (2) TRANSACTION COMMIT
- (2) -- do tabulky se zapisuje 2. řádek s aktualni=true
- -- tabulka obsahuje dva řádky s aktualni=true
Aby hibernate viděla vše, včetně revizí, to není problém - namapuje se i sloupeček s revizí. Aby viděla jen aktuální stav, musel by se zřejmě použít nějaký view na straně databáze.
SQL dotazy by neměl být problém rozšířit o podmínku, o kterou revizi se zajímám. Aktuální verze je pak specíální případ této podmínky - zjistím nejnovější revizi a tu dosadím do předchozí podmínky (v SQL vnořený SELECT).
Varianta s booleanem pro aktuální revizi je sice možná, ale musela by se ošetřit nějakými triggery, jinak hrozí nekonzistence databáze. A obecně informace o tom, která revize je nejnovější, mi dává třeba MAX(revize) (pokud je revize vzestupně číslovaná) - a ukládat do databáze redundantní informaci mi nepřipadá nejlepší.
Jako největší problém bych viděl, jak se má chovat strom objektů v souvislosti s revizemi. Pokud změním A.x, mění se tím revize objektu A - a mění se tím i revize A.z? Naopak, pokud změním A.z.x, mění se tím revize objektu A.z - mění se tím i revize objektu A?
Popíšu ten strom objektů v relačním pojetí. Dejme tomu, že mám záznam A, jedna z jeho položek je id odkazující na záznam B. Součástí toho id může být revize a nemusí. Třeba faktura a adresa - faktura odkazuje na adresu. Může odkazovat buď na id adresy, přičemž adresa samotná může mít několik revizí, ale ve faktuře použiju třeba vždy tu aktuální. Nebo můžu z faktury odkazovat na konkrétní revizi adresy - a když adresu opravím, na faktuře zůstane původní. Ono objektové schéma má ještě další možnost (v relačním trochu krkolomnou) - změním adresu, tím se mi de facto změní i faktura, takže bych měl vytvořit novou revizi i pro fakturu.
Další otázkou taky je, zda "strom objektů" má v relační databázi nějakou přirozenou interpretaci. Pokud ne, může být dodělání revizí už docela oříšek a možná by se vyplatilo poohlédnout se po nějaké objektové databázi nebo třeba XML databázi - i když to ani jedno samo o sobě neřeší problém revizí, může pro některý konkrétní případ být pro takový způsob reprezentace mnohem snazší přidat revize.
Celou dobu jsem předpokládal jen lineární revize, tj pouze vztah starší/novější. Revize ale také můžou být dělány způsobem rodič/potomek, kdy z jedné verze mohou vzniknout dvě a více samostatných nových verzí (můžeme to nazývat větvení, fork, branch...) V takovém případě ani nelze říci, co je aktuální verze, protože verze vytvářejí vlastně strom a aktuální verze jsou všechny jeho listy. Jediná možnost, jak v takovém případě určit, co je aktuální, je některý z listů vybrat a označit ho za aktuální. Tenhle koncept je možné zase rozšířit, můžu mít aktuální prvek pro každou větev. Může to vypadat, že koncept větvení revizí je už příliš složitý, ale prakticky veškerý vývoj softwaru používá tuhle metodu - v jedné větvi se udržuje stabilní verze, v druhé jsou betaverze, v další třeba technologické preview, ve větvi odštěpené z betaverze se vyvíjí samostatná nová funkce... Vlastně jediný mně známý rozšířený případ lineárního verzování je princip Wiki a různá workflow nebo verzované dokumenty. Takže je docela reálné, že z původního požadavku na lineární verzování vznikne brzy požadavek na verzování větvené, ale jeho implementace bude myslím velmi odlišná...
Uff, nemělo by Abíčko kontrolovat, aby zápisek v diskuzi nebyl delší než původní zápiske v blogu?
Někteří lidi jsou strašní grafomani...
Je to takhle nejak?
select * from A aa where x>3 and revize=(select max(revize) from A where id=aa.id)
Ad boolean: uvazoval jsem o transakci, kdy se vlozi novy radek s novou revizi a hned pote se updatene posledni revize a odejme se ten priznak. Nicmene trigger je take reseni.
Ad strom objektu: to je prave tema, ktere jsem v teto diskusi nechtel moc otevirat. Sam v tom nemam zatim moc jasno
Ad vetveni verzovani: brrr Ja chci jen prosty wiki styl, takze aby uzivatel videl, jakymi zmenami dany objekt(y) postupne prosel. Tudiz linearne.
Ad boolean - popisoval jsem to o něco výš - obecně databáze vidí v průběhu transakce databázi v takovém stavu, v jakém byla před začátkem transakce. V tomhle případě by tedy mohly vzniknout 2 a více aktuálních verzí.
SELECT ... FROM ... WHERE revision=0 AND ...
Zde je právě ten problém, že ve výsledku nebudou k dispozici čísla revizí.
Získání skutečného čísla revize:
SELECT max(revision)+1 FROM ... WHERE ...
Vytvoření nové revize bude prostě zkopírování aktuálního záznamu pod novým číslem revize (INSERT).
null. Výkonost by to chtělo otestovat, ale věřím že by to mělo šlapat vcelku rychle.
select * from clanky where child is null;
Tiskni
Sdílej: