Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
Dotaz jsem taky nepochopil. Ale řekněme, že by mohlo být odpovědí už výše uvedené:
select auta.*, paliva.nazev_palivo from tabulka_auta auta, tabulka_paliva paliva where auta.id_palivo = paliva.id_palivo;
Průserem je, pokud některé auto nemá zadané palivo - pak se takové auto nevypíše. Pro tyto případy je lépe použít dotaz:
select auta.*, paliva.nazev_palivo from tabulka_auta auta left join tabulka_paliva paliva using (id_palivo);
Kapitálním průserem by bylo, pokud by snad mnohem rychlejší databáze neuměla left join (nevím):
select auta.*, paliva.nazev_palivo from tabulka_auta auta, tabulka_paliva paliva where auta.id_palivo = paliva.id_palivo union all select auta.*, null from tabulka_auta auta where auta.id_palivo is null;
No a pak, jestli se vám takto složitý dotaz na získání takto jednoduché informace nelíbí, doporučuji view. Jestli vaše databáze view neumí (nevím), zkuste nějakou méně rychlou.
Samozřejmostí při takovém datovém návrhu by měly být cizí klíče - to jen pro sichr, aby vám nějaký nezodpovědný jedinec nezadal do databáze k nějakému auto neexistující palivo, či snad, nedejbobe, nesmazal palivo, na které ještě pořád některé z vašich aut jezdí:
create table tabulka_auta ( .... id_palivo int4 references tabulka_paliva(id_palivo) on update cascade on delete cascade ....
"SELECT id_vyrobce,nazev_vyrobce FROM tb_vyrobce ORDER BY nazev_vyrobce ASC"
. Hle a tady ke kartezkemu součinu nedochází a jména jednotlivých výrobců se neopakují!!
B)U druhého select.boxu je to jasné, na základě vybraného výrobce volám ty modely, kt. mají specifické id ze select.boxu prvního, pomocí WHERE!
C)Třetí select.box se naplňuje řádky z tb_obsah, dotaz je úplně stejný jako u prvního select.boxu: "SELECT id_obsah, nazev_obsah FROM tb_obsah ORDER BY nazev_obsah ASC"
A ZDE DOCHÁZÍ K TOMU KARTÉZKÉMU SOUČINU - PROČ?
$query="SELECT id_obsah, nazev_obsah, id_palivo, nazev_palivo FROM tb_obsah_motoru,tb_palivo ORDER BY nazev_obsah";
$query="SELECT id_obsah, nazev_obsah FROM tb_obsah_motoru ORDER BY nazev_obsah";
Sice to zatim naplní jenom select.box - obsah motoru, ale zato správně(jeden udaj - jedna radka), pouze řádek po řádku
value
z option
do proměnné $carMaker
$carMaker
(což je číselná hodnota, kt. koliduje s hodnotou id_vyrobce v tb_vyrobce) se dosadí do dotazu na model a to v "SELECT id_model, nazev_model FROM tb_model WHERE vyrobce_id=$carMaker ORDER BY nazev_model ASC
". A tím diferencuji modely, kt. se načtou zase do select.boxu - opakuje se zápis proměnné do $carModelnázev sloupce datova hodnota references jmeno_tabulky(název_sloupce, z jiné tabulky?-nevím)on update cascade on delete cascade
create table TBL2( ... COL2 <typ> references TBL1(COL1) ... );znamená, že hodnota sloupce
COL2
musí odpovídat některé hodnotě sloupce COL1
v tabulce TBL1
(nebo být NULL
- podle okolností). Zápis
create table TBLB( ... foreign key (COLB1,...,COLBn) references TBLA(COLA1,...,COLAn) ... );znamená, že v každém řádku tabulky
TBLB
musejí hodnoty sloupců COLB1,...,COLBn
odpovídat hodnotám sloupců COLA1,...,COLAn
v některém řádku tabulky TBLA
.
Přidáte-li 'on update cascade
', při změně odkazovaných hodnot v tabulce TBLA
se odpovídajícím způsobem změní i shodné hodnoty v tabulce TBLB
(jinak byste dostal chybu "violation of foreign key ...
"). Analogicky 'on delete cascade
' při smazání řádku v tabulce TBLA
smaže odpovídající řádky v TBLB
a 'on delete set null
' nastaví hodnoty na NULL
.
No a ještě bych měl jednu připomínku k textu, který jsem napsal včera: v tomto konkrétním případě bych použil nikoli cascade
, ale no action
- pak nejde smazat žádné palivo, na které v databázi některé auto jezdí.
K vašemu stylu zápisu sql dotazů: dlouho jsem ani z příspěvků nechápal, jak dovedete v tak primitivním dotazu vyrobit karteziánský součin - mě se to nestává, vyrobím něco podobného jen zcela vyjímečně. Proti podobným chybám můžu doporučit, abyste vždy zadával všechny všechny tabulky, ze kterých taháte byť i jediný sloupec a dával jim vždy aliasy:
select a.*, b.sloupec2 from tabulka1 a left join tabulka2 b using(klic);
Při takovém stylu zápisu je možnost vzniku kartezského součinu nižší - při překlepech bývá takto zapsaný dotaz nefunční, neproběhne.
Aut, která takto v databázi evidujete, asi nebude mnoho, karteziánský součin vám pouze znepříjemní výstupy. V databázi s milióny záznamů je karteziánský součin mnohem větší legrace - vede to k dotazům, které server není schopen zvládat.
tb_obsah.id_obsah
myslíte, že "povedeny" kartézký součin, lze využit k útoku, je to vůbec možné? teda asi jo, ale to musi utočnik znat strukturu db, a když už ji zna, tak je většinou již uvnitř.
Tiskni
Sdílej: