Jakub Vrána, autor známého Admineru, dal k dispozici knihovnu NotORM. NotORM je nástroj, který usnadní práci s relační databází z objektového prostředí, ačkoli, jak už název napovídá, nejde o ORM. Měl by fungovat nad jakoukoli databází, pro kterou je k dispozici rozhraní PDO.
Simple work with relations is a killer feature of NotORM.
to by chtěl asi říct každej autor nějakýho toolu pro práci s relačníma databázema, ale málokterej autor nějakýho toolu pro práci s relačníma databázema ví co je to ta relace (případně zarputile odmítá to, že by se slovo relace nemělo používat ve významu vztah mezi tabulkama)
a pak otázkopoznámka
//Getting a single row
$application = $software->application[1]; // get by primary key
Díky za rejpnutí, „relation“ jsem změnil na „relationship“.
Syntaxe $db->$table[$id] podporuje jen jednosloupcové primární klíče, je to ale jen zkratka za $db->$table($primary, $id)->fetch(), takže podle více sloupců se dá vyhledat plnou syntaxí. U vztahů to budu muset ještě důkladněji prozkoumat a zdokumentovat. Třeba tabulka application_tag z příkladu vícesloupcový primární klíč má a NotORM s ní nemá problém – u ní by se ale zrovna obešel i úplně bez klíče.
k poslední větě:
1. je v ní nějakej syntax error, nechápu jí na 100%
2. v tom příkladu je vidět akorát že to má ponětí o cizích klíčích, nicméně ten klíč by tam (v db) měl bejt určitě, protože duplicity jsou špatné, áno
Ano, v DB samozřejmě klíč bude. Ale NotORM ho na nic využít nepotřebuje (jinými slovy není nutné, aby tahle tabulka měla jednosloupcový primární klíč). Takže by ani nemusel být primární, ale třeba unikátní.
František Svoboda
15 let před
Ahoj,
zatím tvůj nový nástroj studuji a mám je jednu technickou – ve FAQu v bodu 3 je text „so it is your responsible to escape identifier“ – asi by mělo být responsibility. Jdu studovat dál :)
GPUI Component je open-source Rust knihovna rozšiřující framework GPUI o více než 60 moderních, nativních a multiplatformních UI komponent. Staví na deklarativním přístupu, stateless renderování a jednoduchém API inspirovaném Reactem či Yew. Díky optimalizovanému výkonu, podpoře témat a flexibilním layoutům umožňuje rychlý vývoj desktopových aplikací, jako je například trading nástroj Longbridge Pro. Knihovna je licencována pod Apache 2.0 a dostupná na GitHubu.
Nová verze Vitest 4.0 posouvá hranice testování webových aplikací. Přináší stabilní běh testů přímo v prohlížeči, podporu vizuálního regresního testování i chytřejší práci s lokátory a typováním. Vývojáři tak získávají robustnější, rychlejší a přehlednější nástroje pro zajištění kvality UI i logiky aplikací.
Potřebujete rychle spustit malou mikroslužbu bez složité infrastruktury, ruční správy certifikátů a konfigurace Nginxu? V tomto článku si ukážeme, jak pomocí Bun, Caddy a Dockeru jako univerzálního prostředí vytvořit a nasadit plnohodnotnou mikroslužbu během jedné hodiny.
nejdřív rejpnutí k terminologii (ano, už zase)
Simple work with relations is a killer feature of NotORM.
to by chtěl asi říct každej autor nějakýho toolu pro práci s relačníma databázema, ale málokterej autor nějakýho toolu pro práci s relačníma databázema ví co je to ta relace (případně zarputile odmítá to, že by se slovo relace nemělo používat ve významu vztah mezi tabulkama)
a pak otázkopoznámka
podporuje to složený klíče?
Díky za rejpnutí, „relation“ jsem změnil na „relationship“.
Syntaxe
$db->$table[$id]podporuje jen jednosloupcové primární klíče, je to ale jen zkratka za$db->$table($primary, $id)->fetch(), takže podle více sloupců se dá vyhledat plnou syntaxí. U vztahů to budu muset ještě důkladněji prozkoumat a zdokumentovat. Třeba tabulkaapplication_tagz příkladu vícesloupcový primární klíč má a NotORM s ní nemá problém – u ní by se ale zrovna obešel i úplně bez klíče.rádo se stalo, díky za odpověď
k poslední větě:
1. je v ní nějakej syntax error, nechápu jí na 100%
2. v tom příkladu je vidět akorát že to má ponětí o cizích klíčích, nicméně ten klíč by tam (v db) měl bejt určitě, protože duplicity jsou špatné, áno
Ano, v DB samozřejmě klíč bude. Ale NotORM ho na nic využít nepotřebuje (jinými slovy není nutné, aby tahle tabulka měla jednosloupcový primární klíč). Takže by ani nemusel být primární, ale třeba unikátní.
Ahoj,
zatím tvůj nový nástroj studuji a mám je jednu technickou – ve FAQu v bodu 3 je text „so it is your responsible to escape identifier“ – asi by mělo být responsibility. Jdu studovat dál :)
Díky za upozornění, opravil jsem to.