Byla vydána verze 4.0.0 programovacího jazyka Ruby (Wikipedie). S Ruby Box a ZJIT. Ruby lze vyzkoušet na webové stránce TryRuby. U příležitosti 30. narozenin, první veřejná verze Ruby 0.95 byla oznámena 21. prosince 1995, proběhl redesign webových stránek.
Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
Byla vydána nová verze 7.0 linuxové distribuce Parrot OS (Wikipedie). S kódovým názvem Echo. Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Vývojáři postmarketOS vydali verzi 25.12 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 0.41.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 5.5 (novinky) skriptovacího jazyka Lua (Wikipedie). Po pěti a půl letech od vydání verze 5.4.
Byla vydána nová verze 5.4.0 programu na úpravu digitálních fotografií darktable (Wikipedie). Z novinek lze vypíchnout vylepšenou podporu Waylandu. Nejnovější darktable by měl na Waylandu fungovat stejně dobře jako na X11.
Byla vydána beta verze Linux Mintu 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
GNU Project Debugger aneb GDB byl vydán ve verzi 17.1. Podrobný přehled novinek v souboru NEWS.
Josef Průša oznámil zveřejnění kompletních CAD souborů rámů tiskáren Prusa CORE One a CORE One L. Nejsou vydány pod obecnou veřejnou licenci GNU ani Creative Commons ale pod novou licencí OCL neboli Open Community License. Ta nepovoluje prodávat kompletní tiskárny či remixy založené na těchto zdrojích.
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: