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.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
grep
atd.) a nemusíte řešit žádnou aplikaci pro přístup k těm datům. Implementace takového řešení bude nesrovnatelně jednodušší a bude to flexibilnější.
Požaduješ, aby s každým zápisem vznikla nová verze souboru tak, aby ta předchozí nezanikla, ale jen přestala být vidět?Nieco v tom style potrebujem. Aby ak pride novy subor aby stary nezanikol ale sa niekde odlozil. Aplikacie a ludia by stale spracovali najnovsi a cakali na dalsi. Ten novy by bol stale platny az do prichodu noveho suboru. Pod tym spracovali myslim cast z nich naimportovat do databazy a cast bud len zobrazit alebo dopisat do ineho suboru (to az tak nieje moja starost, co sa s nimi presne deje). Su to vecsinou strukturovane textove subory, kde su cisla a pismena oddelene oddelovacom (csv). Su v nich rozne sumy, cisla, popisy, informacie. Tie subory sa daju rozdeli to viacerych skupin, len cisla, zmiesany text a cisla alebo len text. Vecsina sa da a aj sa spracova tak, ze ich niekto importuje do databazy (my alebo niekto iny) ale ja by som ich radsej vsetky uchovaval ako celok. Pripadalo mi jednoduchsie nasekat ich do databazy v celku ako ich importovat po hodnotach do inej databazy (vzhladom na to, na co si ich chcem odkladat a ako casto s nimi chcem robit). Aj vzhladom na to, ze vsetky nemaju rovnaku strukturu a ta struktura databazy by bola dost zlozita. A moja prefolmulovana otazka znie, ci to ma vyznam riesit cez databazu alebo sa zmierit a len si urobit nejaku adresarovu strukturu, tam ich odkladat a len najst nejaky sposob ako s nimi pracovat. Hlavne mi islo o to, ze napisat SQL select sa mi zda jednoduchsie ako praca s textovymi subormi a to ako z pohladu aplikacie, tak aj cloveka.
cp foo/bar /var/storage/$(date +'%s')Troufnul bych si celou vec timto stylem zbastlit za hodinku. Databaze pro tvoje zadani neprinese naprosto nic. Pokud neco neumis v shellu co umis v sql, radsi ze zeptej zde pritomnych znalcu. Bastlit neco v SQL na co ma unix uz hotove nastroje neni lenost ale blbost.
Z mojho pohladu sa mi zda pouzitie db jednoduche a univerzalne…Z meho pohledu jsi zivy doklad prislovi, ze "kdyz vsechno co mas je kladivo, kazdy problem vypada jako hrebik". Jednoduche? Pokud sql je vsechno co umis a tvoje jedine kriterium je lenost tak mozna. Univerzalni? Jestli ti propriterani protokol pristupny pres specialni knihovnu pripada univerzalnejsi nez neco co je uz desitky let soucasti operacnich systemu, tak ti realita chysta velke prekvapeni.
zapisat jednoduchy select vie urobit viacero nasich uzivatelov ako hrabat sa v textakoch na file systemeOpravdu mate lidi kteri ovladaji sql lepe nez midnight/total commandera? Nejsou spis ty "jednoduche" selecty fantazie ktera nebude uskutecnitelna bez normalizace obsahu tech souboru do neceho nad cim selecty jdou provadet? Protoze z blobu toho moc nevyselectis, vime?
Ak tie datove typy existuju a daju sa pouzit na ulozenie aj ovela vecsich suborov, tak preco ich nepouzit na male textove subory.Protoze bloby jsou urcene k tomu abys jejich obsah mohl spojit s relacnimi daty. Ve tvem pripade kdybys chtel drzet a prohledavat nejaka dalsi metadata. A i v takovych pripadech se casto drzi jen cesta a soubor je na filesystemu. Protoze filesystem, ac ti to asi bude pripadat neuveritelne, je na takovou praci urcen.
Nemam skusenosti s ukladanim suborov do db a tak som sa chcel prv poradit.Oki, poradim ti. Neptej se kdyz nechces slyset odpoved
IMHO jsi tu zcela odůvodnil, že DB význam má, a to jsi ještě nejmenoval např. fulltext, ochranu proti současnému zápisu atd...Asi jsme každý četli jiný komentář.
U malých souborů je db efektivní a dokonce na místo efektivnější než ve FS, protože FS alokuje po sektorech, zatímco DB nikoli.Neporovnávejte databáze s FAT. Existují i lepší souborové systémy. My jako etalon vlastností databází taky nebereme DBF.
A zcela máš pravdu v tom, že uložení v DB dává do budoucna daleko širší možnosti než uložení ve FS.Když řeknete do budoucna a širší možnosti, představím si pro soubory Amazon S3, Hadoop a podobné. Jaká je k tomu alternativa v DB?
Větší nevýhodu má DB jen jednu: o něco pomalejší čtení datPřesněji řečeno minimálně o řád pomalejší čtení. Soubor můžete do sítě poslat tak, že se z disku jednou načte do paměti, jádro předá odkaz aplikaci, ta jej předá do jádra do síťování, a síťová karta data rovnou z paměti cpe do drátů. Když to budete dělat s databází, ta data se budou několikrát v paměti kopírovat a předávat mezi systémem a aplikací.
ale jak vidno, když todle neřeší ani na takovejch serverech jako idnes, imho to nemusíš řešit takyV případě článků to neřeší proto, protože se data mezi čtením a odesláním ještě mnohokrát transformují. Když se budou 150× kopírovat kvůli nějakým šablonám, je nějakých 10 kopírování kvůli čtení z DB už jedno. Ale statické soubory (skripty, styly) posílají ze souborového systému, ne z databáze. YouTube, Picasa, GMail, fotky Facebook - ti bloby samozřejmě neukládají do SQL databáze...
To je u Tebe vcelku obvyklé, že reaguješ na něco jiného.To si nechte pro sebe.
Ne, sory, ale pokud tazatel píše, že bude u každého souboru ukládat jedny a ty samé informace (teda bude ukládat data stejné struktury)Nic takového tazatel nepíše. Tazatel píše, že bude ukládat obsah souboru a jeho název. Existuje nástroj speciálně pro tohle určený -- souborový systém. Mimochodem, Microsoft chtěl mít ve Windows 7 místo souborového sytému databázi. Nakonec to po dlouhém vývoji a zpoždění celých Windows 7 museli odpískat, protože to nebylo použitelné.
e to asi bude i provazovat na nějakou další tabulkuTo zmínil jednou jako možnost, naopak vícekrát výslovně uvedl, že nic jiného než název souboru, čas změny a obsah ukládat nechce.
Který konkrétně souborový systém máš na mysli?Například RaiserFS, JFS nebo Btrfs.
Nemohu tvrdit, že znám všechny, ale zatím jsem neslyšel o žádném, který by neztrácel volné místo díky granularitě.Tady si můžete rozšířit obzory: Comparison of file systems: Allocation and layout policies. Podívejte se na první sloupec, Block suballocation.
Ostatní soubory radši dávají do databázeDo databáze nedávají soubory. Dávají tam články, komentáře atd.
odstavec o Hadoop par beru jako tvoje typické stavění vzdušných zámků a ignorování zadání uživatele.Tak to berete špatně. Byla to reakce na vaše vzdušné zámky o tom, jak databáze dává při uložení BLOBů do budoucna daleko širší možnosti.
cp
samozřejmě umí nepřepisovat cílový soubor. V DB nemám nic zaručený, ale musím znát postup, jak té jednoznačnosti dosáhnout, stejně jako u souborového systému.
psql
, kterým musím nejprve blob vytáhnout z databáze a zapsat jako soubor na disk, abych s obsahem mohl dále pracovat, opravdu nepřináší žádnou výhodu proti tomu, když rovnou pracuju se souborem na disku.
Fulltextový index a databázový index jsou dvě odlišné věci. Když budete chtít nad databází implementovat pořádný fulltext, který má aspoň stopwords, lematizaci a proximitní hledání, budete tam stejně někde mít -- ať už viditelně nebo skrytě -- Lucene nebo něco podobného. Speciální aplikaci pro vyhledávání a udržování indexů není potřeba psát, stačí ji stáhnout a nasadit. Což se v případě databáze musí udělat také.
Navíc DB fultext umí používat snad každej - a pokud ne, tak tutoriál visí na každém kroku, zatímco filesystémovej málokdo a jen nalézt jak na to chvíli potrvá.Nesmíte všechny soudit podle sebe.
Kam ukládají fultextové enginy svá data už je s prominutím úplně ulítlej argument.To je jen reakce na vaši argumentaci, že libovolný blob je vždy vhodné uložit do databáze. Evidentně není. Takže byste se měl zaměřit na to, proč zrovna v případě tazatele je vhodné bloby ukládat do databáze.
Pokud ukládáš data vhodná pro DBSoubory jsou data vhodná pro souborový systém. Pro DB jsou vhodná strukturovaná data.
je pro Tebe více komfort než rychlost
plsql
nebo mysql
nepovažuju zrovna za vrchol komfortu.
view 2012-03-15.log
a prohlížím si jej pohodlně ve vim
u. Jak to děláte vy s databází, že je to ještě snazší a pohodlnější? Proč bych složitě instaloval databázi, psal aplikaci pro ukládání dat, aplikaci pro vyhledávání a pro čtení, když ve vyhledávači mám totéž na třech řádcích? Zdá se mi, že žijete ve 20 století, kdy existovaly jen samostatné vyhledávací enginy a aplikace kolem nich bylo nutné teprve vystavět. Dnes už jsou hotové vyhledávače bezproblémově použitelné. Fulltextový vyhledávač má každý s Windows Vista a vyšší nainstalován na počítači, dále se používají Google Desktop Search a další aplikace. Rozhodně má mnohem víc lidí na počítači nainstalován souborových fulltext než databázový server. V souborovém systému se samozřejmě neuchovává jen obsah souboru, ale také informace o souboru. iDnes pravděpodobně soubory neukládá do databáze, ale v souborovém systému.
apt-get install postgresql
mi nepřipadá o nic jednodušší, než apt-get install solr
.
Copak nepotřebuje ochránit, aby v případě dvou simultáních přenosů se tyto nezapsaly do jednoho souboru? Potřebuje. Takže potřebuje transakce.Nezáleží na tom, jak tomu říkáte, ale operaci "vytvoř soubor, pokud ještě neexistuje", zvládá snad každý souborový systém.
Copak ke každému souboru nebude ukládat ta samá metadata (čas uložení, zdroj, velikost, stav zpracování atd....).Tazatel psal o názvu souboru, čase změny a obsahu souboru. Tyto informace ukládá drtivá většina souborových systémů.
Získaná data nějak popisují činnost služeb. Ta možná bude třeba nějak analyzovat. Takže se budou hodit i agregační funkce, řazení dle různých kritérií.Agregace a řazení nad blobem? Pravděpodobně jste volně přešel k tomu, že se do databáze nebudou ukládat soubory, ale místo toho se soubory rozparsují a do databáze se uloží strukturovaná data. Což je ale úplně jiné zadání. Nějakou posměšnou větičku o neschopnosti držet se zadání si doplňte sám.
dest=$(date +"%y/%m/%d/neco-%s.$$") mkdir -p $(dirname $dest) && cat - > $destZadání splněno, méně než minuta práce… A teď mi zopakuj pohádku o tom jak je v databázi všechno jednodušší
grep
, find
, perl
, head
, tail
atd. Myslel jsem samozřejmě nástroje použitelné pro tento konkrétní případ a zejména pro zpracování těch souborů. Vy neustále operujete nemožností s cp
atomicky vytvořit soubor, přičemž ale žádný rozumný scénář týkající se diskutovaného problémů žádnou takovou operaci nezahrnuje.
Vámi popsaný standardní bezpečný způsob použití v databázi se týká případu bez provázaných tabulek. Sám ale pořád argumentujete tím, jak bude strašně výhodné mít uloženo spoustu dalších dat. Jakmile přidáte další závislé tabulky, běžně používaný způsob přestane být bezpečný. Najednou bude potřeba se starat o transakce, a to nepatří ke standardnímu způsobu práce s MySQL.
Co tvrdím je, že first choice a zároveň nejjednodušší možnost (cp zdroj `$date`) je chybnáAno, je to chybné, ale hlavně proto, že to nedělá nic smysluplného v kontextu této diskuse. Nikde v zadání určitě nebylo, že chce mít tazatel nějaká data uložená dvakrát.
No a nakonec, já netvrdím, že vše ve FS je složitější - opět polemizuješ se svým fantómem. Ano, poté, co přijdeš na race condition a "zaplevelíš"Zatím jste ale nevyřešil, odkud se ta data vůbec vezmou. Ono je totiž dost pravděpodobné, že příprava pro zápis do databáze by spočívala v tom zapsat soubor s unikátním názvem na disk…jméno souboru pidem, a opravíš chybu s atomicitou, tak je furt složitost +- srovnatelná (ovšem nikoli mentální, vymyslet to správně je těžší). Jednodušší i na napsání je vše okolo, tzn. ukládání dalších metadat či práce s nimi, fulltext, indexace dle data (vyhledání událostí od ... do data atd...).
cp
a mv
je dost podstatný rozdíl. Jak z hlediska výsledků, tak z hlediska předpokladů. Např. mv
v rámci jednoho souborového systému je atomická operace, můžete takto bez problémů přesunout soubor, do kterého se stále zapisuje, a mv
s parametrem -n
selže, pokud soubor s cílovým názvem už existuje – navzdory tomu, že vy o tomto chování nevíte.
Je fajn, že jste si konečně všiml, že ten soubor s unikátním názvem už nejspíš někde uložený je. Takže stačí jej přesunout (nebo klidně i okopírovat) do správného adresáře, a je hotovo. O generování unikátního názvu se nemusím starat, protože to zajišťuje již zdrojový soubor.
Jak to "umíte" ukázal Tvůj kolega, který tady dal špatné řešení,Tak to bych si vyprosil. Moje "řešení" měl být příklad jak si to zorganizovat, ošetření závisí na tom jak ty soubory doopravdy vznikají pročež jsem je pominul. Ve skutečnosti se spíše budou přehazovat hotové soubory což je atomické samo o sobě, stdin jsem použil aby se to snadno vyzkoušet. I kdyby data opravdu padaly na stdin, řešení je jak jsi sám poznal, triviální – jeden rename. I kdyby to bylo třikrát tak dlouhé, stále jsi nějak nevysvětlil v čem bude databáze "jednodušší".
Pokud ale z nějakého důvodu (např. nedostatek místa na disku, chyba, nedostatek paměti na serveru, výpadek UPS, nevímco) by byl skript v průběhu příkazu přerušen, v úložišti by zůstal nekompletní soubor.Zatímco v případě databáze by taky mohla zůstat porušená celá databáze. To je opravdu výhra.
data nemusí padat na stdin, mohou padat na nějaký socket, mohou být na jiném FS, na síti, mohou být pro daného uživatele read-only... Ve všech těch případech nemohu použít atomické mv a musím to udělat dvoufázově.Ve všech těchto případech je to problém načítání vstupu, a je potřeba ho ošetřit i při ukládání do databáze. Akorát když to bude dělat člověk, který souborovým systémům nebo síťové komunikaci rozumí, nejspíš na to nezapomene. Když to budete dělat vy, prohlásíte, že zápis do databáze je atomický a není potřeba to řešit, a budete to mít neošetřené.
To by byla docela hloupá databáze, kdyby takovou prkotinu neustála.Pokud ale z nějakého důvodu (...) by byl skript v průběhu příkazu přerušen, v úložišti by zůstal nekompletní soubor.Zatímco v případě databáze by taky mohla zůstat porušená celá databáze. To je opravdu výhra.
Ve všech těchto případech je to problém načítání vstupu, a je potřeba ho ošetřit i při ukládání do databáze. Akorát když to bude dělat člověk, který souborovým systémům nebo síťové komunikaci rozumí, nejspíš na to nezapomene. Když to budete dělat vy, prohlásíte, že zápis do databáze je atomický a není potřeba to řešit, a budete to mít neošetřené.Do databáze? Jaké ošetření? Proč? Transakce se buď udělá, anebo ne. To si databáze ošetří sama.
Do databáze? Jaké ošetření? Proč? Transakce se buď udělá, anebo ne. To si databáze ošetří sama.Přesně jak jsem psal, když někdo slepě věří, že si databáze vše ošetří sama, bude mít program přesně s tou chybou, na kterou tady L0gik pořád vytýká souborům. Tak ještě jednou: když máte na vstupu nekompletní soubor, jak uváděl L0gik, souborový systém ani databáze nic sami neošetří a skončíte s nekompletním souborem v úložišti, ať jím bude souborový systém nebo databáze. Souborový systém v tom má jednu výhodu – pokud budete soubor přesouvat v rámci jednoho souborového systému (což je celkem logické, nedává moc smysl jej kopírovat z harddisku na harddisk), nemusíte se o to starat. Soubor prostě přesunete, a zápis bude plynule pokračovat do „nového“ souboru. V případě databáze tam samozřejmě vždy musíte naprogramovat nějakou logiku, která umí zjistit, že vstup už je celý a je možné zahájit kopírování do databáze.
Tak ještě jednou: když máte na vstupu nekompletní soubor, jak uváděl L0gik, souborový systém ani databáze nic sami neošetří a skončíte s nekompletním souborem v úložišti, ať jím bude souborový systém nebo databáze.Tak ještě jednou: Než budeš příště něco takového tvrdit, ověř si to. Databáze si s tím poradí. Vkládaná data budou buď kompletní, anebo tam nebudou. Nic mezi tím. Totéž platí pro update. Buď původní, anebo nová. Opět kompletní.
Ale kdo tady mluví o nekompletním vstupu?Vy.
UPDATE tabulka obj=cpp(zdrojak);Pokud by při kompilaci došlo k chybě, zůstaly by původní obj a vyvolala by se výjimka. Nemohlo by se stát, že by se část souborů zkompilovala a část ne. Netvrdím, že je to žádoucí chování kompilátorů, ale pokud by zdrojáky byly v DB, neřešili bychom verzování. Verzování v souborovém systému kdysi sice bylo, ale kvůli vysoké ceně médií bylo vytlačeno souborovými systémy bez verzování.
dest=$(date +"%y/%m/%d/neco-%s.$$") mkdir -p $(dirname $dest) && cat - > $dest echo $?Když poběží analyzátor v jiném procesu, musím s tím počítat a soubory do cílového umístění atomicky přesouvat. Když poběží analyzátor v jiném procesu, musím s tím v drtivé většině případů počítat i v databázi. V některých hodně jednoduchých případech to bude fungovat správně i tehdy, když s tím počítat nebudu, ale vědět, které to jsou, to vyžaduje dost podrobné znalosti konkrétní databáze.
FS neposkytuje efektivní nástroje pro transakceV tom se shodneme. Akorát že transakce jsou při zpracování logů málokdy potřeba.
cp
má parametr -n, který zakáže přepis cílového souboru. Když vy si můžete stanovit, že použitá databáze umí sekvence, já si můžu stanovit, že použité cp
umí nepřepisovat soubory.
Psal jste o případu, kdy se zdrojový soubor začne zpracovávat dříve, než je zapsán celý. Zpracování může být jak kopírování jinam, tak zápis do databáze. Opravdu ani databáze si neumí správný obsah souboru domyslet. Neznalost úplně elementární věci je to na vaší straně – vymyslíte si tvrzení, že zápis do databáze je atomický (které je nic neříkající, někdy to pravda být může, někdy nemusí), zapomenete, že vlastně píšete o čtení ze souboru, a nesmysl je na světě.
SELECT NEXT VALUE FOR moje_sequence ;
INSERT INTO tabulka (id, ...) VALUES (*ziskane_id*)
anebo (tady pro postgresql)
INSERT INTO tabulka (...) VALUES ();
SELECT curval(moje_sequence);
a taky to nebude trpět chorobou z konkurečního přístupu, i když to neudělám v transakci. Překvápko, co? Vidím, že fakt "umíš". (sorry za sarkasmus, ale todle fakt nejde, normální člověk dřív, než něco takhle opakovaně tvrdí, tak si to aspoň zkontroluje, že to tak opravdu je, jinak je za blbce).
A navíc v každé db je funkce na zjištění ID vloženého záznamu (LAST_INSERT_ID v Mysql, RETURNING clause v Postgresql, Oracle, Firebird), takže těch cest je X a pokud neudělám select zpět na tabulku (což je ta úplně nejhloupější cesta a navíc nesmyslná, protože select má smysl pouze pokud umím záznam identifikovat a pak to ID vlastně ani nepotřebuju), tak transakci nepotřebuje snad žádná.
---
Vzhledem k tomu, že o vstupu nic konkrétního nevíme, tak je normální předpokládat, že je korektní (předpokládal to i Tvůj kolega).
A ano, analyzátor může začít zpracovávat soubor vzniklý z korektního vstupu dříve, než ho v příkladu prezentované řešení pomocí cat zapíše celý, zatímco v databázi se to opravdu stát nemůže.
Atomicita je přesně daný termín, pokud se bavíte o takovýchto věcech a nevíte co to znamená, tak no comment. Tak si to přečtěte na wiki. Operace nad databází (pokud nepoužívají externí funkce přistupující jinam, ale to už pak není čistě DB operace) jsou atomické vždy z definice, nikoli pouze někdy, jak tvrdíte. To Ti už dokládat nebudu, už mě to nebaví, nechám to Tvému samostudiu.
cp
nebo GNU mv
?
To se fakt chceš až tak ztrapnit až tak, že nevíš, že operace nad sekvencema je by definition nezávislá na transakcích?Myslel jsem si, že aspoň o těch databázích něco víte. Teď vidím, že jsem se mýlil.
To je ten běžný postup, který se všude používá?SELECT NEXT VALUE FOR moje_sequence ; INSERT INTO tabulka (id, ...) VALUES (*ziskane_id*)
aneboVýjimka asi nebude přesně to, co jsem chtěl získat. Zapomněl jste totiž na to, žeINSERT INTO tabulka (...) VALUES (); SELECT curval(moje_sequence);
curval()
funguje jen v rámci jedné session.
A navíc v každé db je funkce na zjištění ID vloženého záznamuA všechny logicky vyžadují buď stejnou transakci nebo stejnou session. Což se nezařídí samo od sebe, ale musí o tom programátor vědět a napsat to tak. Když to nevíte ani vy, jak na tom asi bude ten programátor?
A ano, analyzátor může začít zpracovávat soubor vzniklý z korektního vstupu dříve, než ho v příkladu prezentované řešení pomocí cat zapíše celý, zatímco v databázi se to opravdu stát nemůže.V příkladu řešení pomocí
cat
by analyzátor logicky začal práci až po úspěšném dokončení cat
u. Pro databázi lze samozřejmě taky vymyslet nějaké hodně hloupé řešení, které se bude pokoušet číst data z databáze dřív, než tam budou zapsaná. Třeba ten váš slavný první kód rozšíří programátor takhle, a bude volat klasicky každý příkaz zvlášť, tedy v nové transakci a potenciálně v nové session:
SELECT NEXT VALUE FOR moje_sequence ; INSERT INTO tabulka (id, ...) VALUES (*ziskane_id*); CALL analyze(*ziskane_id*);
cp
může nějakou dobu trvat, než že musí dávat pozor na to, odkud bere databázové spojení a zda má zaručeno, že se pro oba dva příkazy použije to samé. Ono úplně stačí, že si to pěkně rozdělí do dvou funkcí, v každé si řekne poolu uloženému v kontextu o databázové spojení, a problém je na světě.
mv
na stejném souborovém systému, ať dá ruce pryč od programování.
K poslednímu odstavci bych jen dodal to, že při dodržení některých základních pravidel dostanu od databáze lepší podporu pro transakční zpracování. Což na druhou stranu vede na neopodstatněné spoléhání na to, že databáze správně zařídí transakčnost, i v případech, kdy tomu tak není.
git grep
), je to inkrementální a jako bonus se z toho dá dostat informace, jaké změny kdy byly. A existujou pro to grafická klikátka (qgit, gitg, gitk, giggle ...).
A když po commitu uděláš i push někam na server, tak budeš mít i zálohy.
Tiskni
Sdílej: