Byla vydána nová verze 6.12 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přináší důležité bezpečnostní opravy díky bezpečnostnímu auditu od společností Radically Open Security. Tor Browser byl povýšen na verzi 14.0.5. Thunderbird na verzi 128.6.0. Další změny v příslušném seznamu.
Databáze DuckDB (Wikipedie) byla vydána ve verzi 1.2.0. S kódovým názvem Histrionicus (kačka strakatá). Z novinek lze vypíchnout, že například 🦆 může být nově použita jako vícebajtový oddělovač sloupců. 😂
Google Chrome 133 byl prohlášen za stabilní. Nejnovější stabilní verze 133.0.6943.53 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 12 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Novinky v Knot Resolver 6: ochrana před DoS útoky – technické řešení, aktuální příspěvek na blogu zaměstnanců CZ.NIC.
Smb4K, tj. pokročilý prohlížeč síťového okolí a nástroj na připojování úložišť Samba, byl vydán v nové major verzi 4.0.0. Proběhla portace na Qt 6 a KF 6.
V červnu loňského roku představena RISC-V základní deska pro Framework Laptop 13 je již v prodeji. Její cena je 4990 Kč. Díky otevřenosti Framework Laptopů začínají vznikat moduly třetích stran, například SDR modul nebo modul s dotykovým e-paperem.
Video Game History Foundation (VGHF, Wikipedie), tj. nadace zabývající se historii videoher byla založena v únoru 2017. Od svého vzniku buduje také digitální knihovnu. Po letech katalogizace, zpracovávání a digitalizace svých sbírek ji otevřela veřejnosti. Zdarma, pro všechny a odkudkoli: Library a Digital Archive.
Byl vydán Mozilla Firefox 135.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 135 je již k dispozici také na Flathubu a Snapcraftu.
Dnes vychází Kingdom Come: Deliverance II (Wikipedie), pokračování počítačové hry Kingdom Come: Deliverance (Wikipedie, ProtonDB Gold).
Zdravím.
Mám Postgres 8.0.13, v ňom databázu s takýmito tabuľkami:
CREATE TABLE uzivatel ( id SERIAL NOT NULL, meno VARCHAR NOT NULL, PRIMARY KEY (id) ); INSERT INTO uzivatel (meno) VALUES ('Jozko'); -- dostane id = 1 INSERT INTO uzivatel (meno) VALUES ('Ferko'); -- dostane id = 2 INSERT INTO uzivatel (meno) VALUES ('Samko'); -- dostane id = 3 CREATE TABLE uloha ( id SERIAL NOT NULL, zadavatel INT REFERENCES uzivatel (id) ON UPDATE CASCADE ON DELETE SET NULL, riesitel INT REFERENCES uzivatel (id) ON UPDATE CASCADE ON DELETE SET NULL, kontrolor INT REFERENCES uzivatel (id) ON UPDATE CASCADE ON DELETE SET NULL, -- plus nejake dalsie nepodstatne stlpce PRIMARY KEY (id) ); INSERT INTO uloha (zadavatel, riesitel, kontrolor) VALUES (1,NULL,NULL); INSERT INTO uloha (zadavatel, riesitel, kontrolor) VALUES (2,2,NULL); INSERT INTO uloha (zadavatel, riesitel, kontrolor) VALUES (3,3,3);
T.j. sú tam užívatelia a úlohy k nim. Eviduje sa kto úlohu zadal, kto ju rieši (resp. riešil) a kto ju skontroloval. Je to ošetrené referenciami tam, aby zmazanie užívateľa nastavilo v príslušnom stĺpci NULL. Problém nastáva, ak vo všetkých 3 stĺpcoch je tá istá hodnota (ten istý užívateľ). Pri pokuse o vymazanie takého užívateľa sa to zasekne, namiesto toho aby nastavilo všade NULL:
araxon=# DELETE FROM uzivatel WHERE id=1; -- toto je v pohode DELETE 1 araxon=# DELETE FROM uzivatel WHERE id=2; -- toto je este tiez v pohode DELETE 1 araxon=# DELETE FROM uzivatel WHERE id=3; -- a toto uz je problem ERROR: insert or update on table "uloha" violates foreign key constraint "uloha_kontrolor_fkey" DETAIL: Key (kontrolor)=(3) is not present in table "uzivatel". CONTEXT: SQL statement "UPDATE ONLY "public"."uloha" SET "riesitel" = NULL WHERE "riesitel" = $1"
T.j. ak sú referencie na užívateľa len v jednom či dvoch stĺpcoch, tak to ide, ale v troch a viac sa to už sekne. Vyzerá to, že pri mazaní toho tretieho užívateľa to opraví prvé dve referencie (zadavatel, riesitel) a potom sa pokúsi užívateľa vymazať nehľadiac na tretiu referenciu (kontrolor). Bude to najskôr nejaký limit, ktorý je v Postgresi zakomponovaný natvrdo. Ak sa na ten istý záznam odkazujú len ľubovoľné 2 stĺpce, tak to ide bez problémov, ak ich je viac, tak to už zlyhá. Nenašiel som k tomuto nič v dokumentácii, ani na fórach, tak sa pýtam: nestretol sa s tým niekto? Viem, že je možné zmeniť štruktúru aplikácie, ale toto je len príklad - v skutočnosti to máme zložitejšie, týka sa to viacerých tabuliek a je to nasadené kade-tade. Tento problém nie je vôbec častý, akurát trochu nahlodáva moju vieru v to, že všetko vždy bude fungovať tak ako má.
Otázka teda znie: dá sa tento limit nastaviť v konfigurácii, alebo pri kompilácii postgresu? Rád by som to vyriešil bez toho aby trebalo meniť aplikáciu - o referenčnú integritu sa má starať databáza, a nie že to bude kontrolovať ešte aj aplikácia.
Řešení dotazu:
CREATE TABLE users ( id SERIAL NOT NULL, name VARCHAR NOT NULL, PRIMARY KEY (id) ); INSERT INTO users VALUES (1, 'Jozko'); INSERT INTO users VALUES (2, 'Ferko'); INSERT INTO users VALUES (3, 'Samko'); CREATE TABLE tasks ( id SERIAL NOT NULL, owner INT REFERENCES users (id) ON UPDATE CASCADE ON DELETE SET NULL, worker INT REFERENCES users (id) ON UPDATE CASCADE ON DELETE SET NULL, checked_by INT REFERENCES users (id) ON UPDATE CASCADE ON DELETE SET NULL, PRIMARY KEY (id) ); INSERT INTO tasks VALUES (1,NULL,NULL); INSERT INTO tasks VALUES (2,2,NULL); INSERT INTO tasks VALUES (3,3,3); DELETE FROM users WHERE id = 1; -- works simple DELETE FROM users WHERE id = 2; -- works ok DELETE FROM users WHERE id = 3; -- doesn't work, why
CREATE TABLE users ( id integer NOT NULL, name VARCHAR NOT NULL, PRIMARY KEY (id) ); INSERT INTO users VALUES (1, 'Jozko'); INSERT INTO users VALUES (2, 'Ferko'); INSERT INTO users VALUES (3, 'Samko'); CREATE TABLE tasks ( id integer NOT NULL, owner INT REFERENCES users (id) ON UPDATE CASCADE ON DELETE SET NULL INITIALLY DEFERRED, worker INT REFERENCES users (id) ON UPDATE CASCADE ON DELETE SET NULL INITIALLY DEFERRED, checked_by INT REFERENCES users (id) ON UPDATE CASCADE ON DELETE SET NULL INITIALLY DEFERRED, PRIMARY KEY (id) ); INSERT INTO tasks VALUES (1,1,NULL,NULL); INSERT INTO tasks VALUES (2,2,2,NULL); INSERT INTO tasks VALUES (3,3,3,3); DELETE FROM users WHERE id = 1; -- works simple DELETE FROM users WHERE id = 2; -- works ok DELETE FROM users WHERE id = 3; -- works tooDocela bych rekl, ze se jedna o bug postgresql (vlastnost), resp. nedomyslenost pri vyhodnocovani podminek. Pavel
INITIALLY DEFERRED
to chodí.
Tiskni
Sdílej: