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
16 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 :)
Interní platforma nemusí začít velkým vývojářským portálem. Příklad `opr-paas` ukazuje skromnější začátek: tým popíše projekt v YAML a platforma mu podle něj připraví namespacy, práva, kvóty, síťová pravidla i úklid dočasných prostředí. Samotný namespace ale tým v Kubernetes bezpečně neoddělí.
Založit účet u banky bez občanského průkazu už dnes prakticky nejde. Když ale stejný doklad začne vyžadovat chatbot, je to signál, že se něco mění. Ověřování identity (KYC), které bylo donedávna doménou finančního sektoru, proniká do světa umělé inteligence. Co za tím stojí, jaké jsou regulatorní důvody a proč bychom měli přemýšlet o tom, kolik osobních údajů jsme ochotni za používání AI služeb obětovat?
WordPress pohání přes 43 % celého webu. Právě proto je terčem neustálých útoků. Jenže kdykoli se objeví titulkové zprávy o „napadených WordPress webech", klíčový detail bývá pohřben v posledním odstavci — nebo chybí úplně: samotné jádro WordPressu je za útok zodpovědné jen výjimečně.
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.