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.
Valkey, tj. svobodný fork již nesvobodného Redisu, byl vydán v první stabilní verzi 7.2.5.
Společnost Espressif Systems oznámila, že rodinu SoC ESP32 brzy rozšíří o ESP32-H4 s IEEE 802.15.4 a Bluetooth 5.4 (LE) s podporou protokolů Thread 1.3, Zigbee 3.0 a Bluetooth Mesh 1.1.
Kevin Bentley zveřejnil na GitHubu zdrojové kódy počítačové hry Descent 3 z roku 1999: "Někdo se nedávno zeptal, zda budou zveřejněny zdrojové kódy Descent 3. Oslovil jsem svého bývalého šéfa (Matt Toschlog) z Outrage Entertainment a ten mi to povolil. Budu pracovat na tom, aby se to znovu rozběhlo a hledám spolusprávce." [Hacker News]
Byla vydána verze 0.81 telnet a ssh klienta PuTTY. Opravena je kritická bezpečnostní chyba CVE-2024-31497 obsažena ve verzích 0.68 až 0.80. Používáte-li klíč ECDSA NIST P521 a použili jste jej v PuTTY nebo Pageantu, považujte jej za kompromitovaný.
Hra MineClone2 postavena nad voxelovým herním enginem Minetest byla přejmenována na VoxeLibre.
Ahoj vsem, poteboval bych poresit jednu vec.
Mam tabulku se zaznamy tvorenymi polozkami x a y, ktera vypada nejak takhle
CREATE TABLE "tab" (
x varchar(64);
y varchar(64);
created DATETIME;
last DATETIME;
UNIQUE ( x, y);
)
Krome polozek x a y obsahuje tabulka i dva casove udaje - kdy byl zaznam porizen a kdy byl naposledy kontrolovan.
Samotne zaznamy by mely byt unikatni, nemenne, pri pokusu o vlozeni stejneho zaznamu by melo dojit jen k prepsani znacky 'last'.
Myslim, ze to neni az tak neobvyykla uloha. Je mozne zajistit preklopeni pokusu o vlozeni na update znacky last pomoci triggeru? Primarne bych to chtel v sqlite, ale nebranim se ani reseni v jinych DB.
ano, jde to. A často se to tak dělá.
sqlite: dokumentace a příklady
A mohl bych vedet jak?
Googlit jsem samozrejme zkousel, zkousel jsem par desitek pokusu, ale porad ne a ne prijit na to jak :(
snadno
-- Script started
CREATE TABLE tab
(
x VARCHAR2(64),
y VARCHAR2(64),
created DATETIME,
updated DATETIME,
unique(x, y)
);
-- No error
--
CREATE TRIGGER t_tab_insert
AFTER INSERT ON tab
FOR EACH ROW
BEGIN
UPDATE tab SET created = DATETIME('NOW')
WHERE x = new.x
AND y = new.y;
END;
-- No error
--
CREATE TRIGGER t_tab_update
AFTER UPDATE OF x, y ON tab
FOR EACH ROW
BEGIN
UPDATE tab SET updated = DATETIME('NOW')
WHERE x = new.x
AND y = new.y;
END;
-- No error
--
insert into tab values ('1', '1', null, null);
-- No error
--
insert into tab values ('1', '2', null, null);
-- No error
--
select * from tab;
-- No error
-- x y created updated
-- - - ------------------- -------
-- 1 1 2009-01-28 13:34:54 {null}
-- 1 2 2009-01-28 13:34:55 {null}
update tab set x = '2';
-- No error
--
select * from tab;
-- No error
-- x y created updated
-- - - ------------------- -------
-- 2 1 2009-01-28 13:34:54 2009-01-28 13:35:36
-- 2 2 2009-01-28 13:34:55 2009-01-28 13:35:36
-- Script finished
Jiné DB neš sqlite mají pochopitelně jiné možnosti. Takže by to šlo udělat jendím triggerem 9IF UPDATING... apod.)
ale fakt bude lepší, kdyby sis přešetl nějakou SQL příručku a dokumentaci k tvé DB.
Diky,
tohle jsem taky zkousel, ale me jde o to, aby kdyz udelam znovu insert toho sameho, tak abych misto hlasky o poruseni omezeni docilil ten update.
sqlite> insert into tab values ('1', '1', null, null);
sqlite> insert into tab values ('1', '2', null, null);
sqlite> insert into tab values ('1', '1', null, null);
SQL error: columns x, y are not unique
Dokumentaci mam prectenou horem dolem, jinak bych se neptal :)
U toho REPLACE se rika, ze pre-existing rows that are causing the constraint violation are removed. To mi ale vadi, protoze tim prijdu o puvodni hodnotu sloupce created. To uz mi prislo zajimavejsi to IGNORE ale s tim jsem taky niceho nedosahl.
Idealni by bylo, kdy k tomu ON CONFLICT sla pripojit vlastni procedura nebo by sla odchytit ta chybova vyjimka, ale to tady nejde. Napadlo me i odstranit ten constraint a delat ho rucne v triggeru i kdyz to mi neprijde jako moc efektivni. Myslel jsem, ze by to mohla byt pomerne casta uloha a zajimalo me, jestli na to neni nejaka znama finta, at uz v sqline nebo jine DB.
CREATE TABLE tab
(
x VARCHAR2(64),
y VARCHAR2(64),
unique(x, y) on conflict replace
);
create table tab_audit
(
x VARCHAR2(64),
y VARCHAR2(64),
dml_action varchar2(10),
stamp DATETIME
);
CREATE TRIGGER t_tab_insert
AFTER INSERT ON tab
FOR EACH ROW
BEGIN
insert into tab_audit
values (new.x, new.y, 'INSERT', DATETIME('NOW'));
END;
CREATE TRIGGER t_tab_update
AFTER UPDATE OF x, y ON tab
FOR EACH ROW
BEGIN
insert into tab_audit
values (new.x, new.y, 'UPDATE', DATETIME('NOW'));
END;
insert into tab values ('1', '1');
insert into tab values ('1', '1');
insert into tab values ('1', '2');
select * from tab;
select * from tab_audit;
update tab set x = '2';
select * from tab;
select * from tab_audit;
Aktuální stav dohledáš (outer) joinem, historii selektem. Jo, a nejsou tam indexy.
Anebo to ošetři v klientský aplikaci jako UPSERT.
V Oracle jde toto pomoci merge (tedy neni to uz insert) - definuje se co se ma stat pokud zaznam existuje (typicky update) a co pokud neexistuje (typicky insert). Samozrejme triggerem by to slo i v Oracle.
Dovedu si predstavit, ze se takovy trigger muze nekdy hodit, nicmene mam s tim dost spatne zkusenosti. Pokud insert uz neni ve skutecnosti insert, muze to nekdy byt docela matouci, takze tam kde to jde preferuji explicitni reseni (zmineny merge nebo select a podle vysledku insert/update) - kazdemu je pak z kodu jasne, co se vlastne v tabulce stane.
Tiskni Sdílej: