Cursor (Wikipedie) od společnosti Anysphere byl vydán ve verzi 2.0. Jedná se o multiplatformní proprietární editor kódů s podporou AI (vibe coding).
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.
CREATE TABLE objekt ( id numeric NOT NULL, -- Identifikace jedinečná pro všechny objekty v systému nazev character varying, -- Název objektu CONSTRAINT objekt_pk PRIMARY KEY (id) ) WITH (OIDS=FALSE); ALTER TABLE objekt OWNER TO piskoviste; COMMENT ON COLUMN objekt.id IS 'Identifikace jedinečná pro všechny objekty v systému'; COMMENT ON COLUMN objekt.nazev IS 'Název objektu'; CREATE TABLE clanek ( -- Inherited: id numeric NOT NULL, -- Inherited: nazev character varying, "text" text, -- Text článku CONSTRAINT clanek_pk PRIMARY KEY (id) ) INHERITS (objekt) WITH (OIDS=FALSE); ALTER TABLE clanek OWNER TO piskoviste; COMMENT ON COLUMN clanek."text" IS 'Text článku';Problém ale je, že primární klíč funguje jen na danou tabulku, např. předka a nezabrání tomu, abych měl objekt s id = 1 a článek s id = 1 a pak když selektuji všechny objekty (včetně článků), dostanu výstup s duplicitními id. Další problém bude s cizími klíči, když budu chtít navázat třeba ty komentáře na objekt. Samozřejmě jsem udělal RTFM a zjistil jsem, že oficiální dokumentace tyhle problémy popisuje. Řešení ale chybí, jen se tam píše, že tyhle nedostatky budou napraveny někdy v příštích verzích. Existuje nějaký způsob, jak dědičnost využít k mému účelu, nebo se na to mám vykašlat a udělat to klasicky*? Případně použít jako identifikátor OID? Ale nevím, jak moc dobré řešení to je (řešilo by to PK, ale ne FK). *) Víc tabulek provázaných přes cizí klíče, kde „potomci“ budou mít jako PK cizí klíč do tabulky „předka“ + nějaké pohledy, které udělají souhrn společných sloupečků všech potomků.
SELECT o.*, pg_class.relname FROM objekt o JOIN pg_class ON (o.tableoid = pg_class.oid);…seznam objektů včetně jejich typu (resp. názvu tabulky)
Ještě před usnutím mě jedno řešení napdalo: vytvořím si pomocnou tabulku objekt_id, která bude obsahovat seznam ID objektů, a funkci zalozObjekt(), která vezme nové ID ze sekvence a zároveň založí záznam v objekt_id. Tuhle funkci použiji jako výchozí hodnotu sloupečku místo přímého selektování sekvence.
CREATE SEQUENCE komentar_seq INCREMENT 1 MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1;
CREATE SEQUENCE objekt_seq INCREMENT 1 MINVALUE 1 MAXVALUE 9223372036854775807 START 2 CACHE 1;
CREATE TABLE objekt_id
(
id bigint NOT NULL,
CONSTRAINT objekt_id_pk PRIMARY KEY (id),
CONSTRAINT objekt_fk FOREIGN KEY (id)
REFERENCES objekt_id (id) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
COMMENT ON TABLE objekt_id IS 'Tabulka navíc, abychom obešli problém s PK a dědičností.
Žádná data, jen seznam primárních klíčů objektů';
CREATE OR REPLACE FUNCTION zalozobjekt()
RETURNS bigint AS
$BODY$DECLARE id BIGINT;
BEGIN
SELECT INTO id nextval('objekt_seq');
INSERT INTO objekt_id VALUES (id);
return id;
END;$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 100;
CREATE TABLE objekt
(
id bigint NOT NULL DEFAULT zalozobjekt(), -- Identifikace jedinečná pro všechny objekty v systému
nazev character varying, -- Název objektu
CONSTRAINT objekt_pk PRIMARY KEY (id),
CONSTRAINT clanek_fk FOREIGN KEY (id)
REFERENCES objekt_id (id) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
COMMENT ON COLUMN objekt.id IS 'Identifikace jedinečná pro všechny objekty v systému';
COMMENT ON COLUMN objekt.nazev IS 'Název objektu';
CREATE TABLE clanek
(
-- Inherited: id bigint NOT NULL,
-- Inherited: nazev character varying,
"text" text, -- Text článku
CONSTRAINT clanek_pk PRIMARY KEY (id)
)
INHERITS (objekt)
WITH (OIDS=FALSE);
COMMENT ON COLUMN clanek."text" IS 'Text článku';
CREATE TABLE komentar
(
id bigint NOT NULL DEFAULT nextval('komentar_seq'::regclass),
nadpis character varying NOT NULL,
"text" text NOT NULL,
objekt bigint NOT NULL,
odpoved_na bigint,
CONSTRAINT komentar_pk PRIMARY KEY (id),
CONSTRAINT komentar_objekt_fk FOREIGN KEY (objekt)
REFERENCES objekt_id (id) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT komentar_odpoved_fk FOREIGN KEY (odpoved_na)
REFERENCES komentar (id) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
CREATE INDEX fki_komentar_objekt_fk
ON komentar
USING btree
(objekt);
CREATE INDEX fki_komentar_odpoved_fk
ON komentar
USING btree
(odpoved_na);
CREATE OR REPLACE VIEW trida_objektu AS
SELECT o.id, o.nazev, pg_class.relname
FROM objekt o
JOIN pg_class ON o.tableoid = pg_class.oid;
Zatím to vypadá, že to funguje – řeší to problém jedinečnosti ID přes předka a všechny potomky a problém s cizími klíči (např. navázání komentářů).
Ale přijde mi to jako dost velká obebávka, tak by mě zajímalo, co si o tom myslí Pavel Stěhule nebo někdo podobný 
S dědičností je to asi tak - když jsem si poprvně přečetl manuál, řekl jsem si super. A než jsem se dostal k projektu, kde bych ji mohl použít, tak jsem krapet vystřízlivěl. Dědičnost má smysl, tam kde mám dynamické schéma - tj. kde využiju toho, že po přidání potomka vidím data i v rodiči. Jinak nevidím důvod ji použít. A ohledně té obebavky - s Petrem Krontorádem http://www.krontorad.com/ jsme vymýšleli objektový db backend pro menší aplikace. Výsledná struktura byla docela podobná. Šli jsme na to o fous univerzálněji - měli jsme popisný jazyk pro popis objektů - skripty v něm se po vykonání přeložily v SQL příkazy, které jednak vytvářely podobné schéma, jednak plnily tabulky s metadaty, vytvářely potřebné indexy, atd.
Funkci zaloz_objekt bych asi napsal o něco úsporněji (všechny tři příkazy lze sloučit do jednoho pomocí klauzule RETURNING):
Díky za odpověď. Schchéma až tak dynamické nebude, ale asi u dědičnosti zůstanu, pokud se neobjeví nějaký velký problém (líbí se mi např. ten snadný způsob zjištění typu objektu pomocí pohledu).
Ještě bych měl dotaz: nějak cítím, že by bylo systémově lepší, kdyby potomkem objektu byly úplně všechny objekty v systému (včetně komentářů, hlasování atd.). Ale tyhle věci jako objekty mít nepotřebuji a navíc se obávám, že by tabulka objekt_id narostla do zbytečně velkých rozměrů a nic by to nepřineslo. Naopak by její velikost mohla způsobovat zpomalení. Co bys volil ty – univerzální řešení (všechno je potomkem objektu) nebo mít jako objekty jen ty tabulky, u kterých to má smysl?
To vubec nedokazu rict - je to otazka citu - treba komentare beru spise jen jako property u clanku (ale zalezi na kontextu). Pokud uz bych ale pracoval s objekty - tak spis bych vychazel z jednoho predka - to ostatni bych vubec nepovazoval za objekty.
Tiskni
Sdílej: