#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.0.0. Přehled novinek v poznámkách k vydání.
Nejvyšší soud podpořil novináře Českého rozhlasu. Nařídil otevřít spor o uchovávání údajů o komunikaci (data retention). Uvedl, že stát odpovídá za porušení práva EU, pokud neprovede řádnou transpozici příslušné směrnice do vnitrostátního práva.
Minulý týden proběhl u CZ.NIC veřejný test aukcí domén. Včera bylo publikováno vyhodnocení a hlavní výstupy tohoto testu.
Byla vydána nová verze 3.5.0 svobodné implementace protokolu RDP (Remote Desktop Protocol) a RDP klienta FreeRDP. Přehled novinek v ChangeLogu. Opraveno bylo 6 bezpečnostních chyb (CVE-2024-32039, CVE-2024-32040, CVE-2024-32041, CVE-2024-32458, CVE-2024-32459 a CVE-2024-32460).
Google Chrome 124 byl prohlášen za stabilní. Nejnovější stabilní verze 124.0.6367.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 22 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byla vydána nová verze 9.3 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Novinkou je vlastní repozitář DietPi APT.
Byl vydán Mozilla Firefox 125.0.1, první verze z nové řady 125. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vypíchnout lze podporu kodeku AV1 v Encrypted Media Extensions (EME). Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 125.0.1 je již k dispozici také na Flathubu a Snapcraftu.
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: