Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
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.
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: