Je tu leto, je čas oddychovať a prestať brať veci vážne. Musk ale nikdy nespí, a tak prišiel na ďalší geniálny nápad. Veď všetci scanujú Twitter, vykrádajú jeho texty, a tak zablokoval prístup k Twitteru pre neprihlásených užívateľov. Skutočný dôvod blokovania ale je, že Twitter hostuje svoje servery v Google Cloude a takto chce redukovať náklady.
Polemika: Je ORM anti pattern?
O tejto polemike som cital uz hadam pred desiatimi rokmi. Za mna, ORM nie je akademicky ciste, ale je velmi vyhodne a prispieva k produktivite. Je to velmi podobne ako hadka o tom ci je anemicky domenovy model antipatern.
A tiez to vypliva z toho, ze je vela roznych typov ORM.
Povedzme si, čo naozaj ORM je. Je to query generátor.
S tymto nesuhlasim, ORM je mapper relacnych entit na objekty.
My dotnetisti sme hickany a rozmaznavany LINQ-om a Entity Frameworkom, no dlho pred tym som robil s ORM-kami v PHP-čku a tam vytvorenie query bola najbolestivejsia cast toho vsetkeho (a kedze sa vsteko zadavlo ako pole stringov, tak som na intelisense mohol zabudnut).
Napriklad (aj ked je to nezmyselny priklad):
Articles::findAll(array(
'WHERE' => 'cathegorry_id = :id AND NOT deleted',
'GROUP_BY' => array('author_id')
),
array(':id'=>$cathegorry_id ));
Vpodstate ked som napisal SQL-ko, tak to bolo kratsie 
Pamätám si z dávnych dôb, kedy sa ako hlavný dôvod pre použitie ORM uvádzalo, že môžete zmeniť databázu, na ktorej beží vaša aplikácia. Pravdu povediac za celú dobu, čo som programátorom, som sa s tým v praxi nestretol.
Kedze robim produktovy vyvoj uz som sa s tym niekolkokrat stretol. Paradoxne toto bolo v EF6 (tam to fungovalo bez problemov) lahsie ako v EF Core (tu uz treba viac testovat). No viacmenej bolo dopredu dane na akych databazach to ma bezat.
Ku ORM mam este jednu vec, casto pocujem argument, ze robi s databazy len tupe ulozisko. No to tiez zalezi na type ORM, Entity Framework tym rozhodne netrpi a v pripade Sqlite a MySQL tam tej funkcionlity a typov este pridava 
A mikroorm mam tiez rad, uz cakam na DapperAOT no ten pride az s .Net 8 (kvoli interceptorom).
Aby sme vedeli ľahšie robiť query?
Napr. v PHP to nemajú pekne cez Linq, ale majú svoj vlastný DQL jazyk. Je to string, ale princip ten istý Doctrine Query Language. Hibernate s HQL to isté Chapter 14. HQL: The Hibernate Query Language. Je to abstrakcia, aby nemuseli rozmýšľať nad on väzbami.
Tu je to myslené tak, že máš ORM definíciu a nevráti ti jeden objekt, ale objektový strom podľa ORM špecifikácie.
Keď od začiatku vieš, že to má bežať na týchto DB, tak je to súčasť špecifikácie. Je rozdiel od sľubu, že s ORM môžete kedykoľvek zmeniť podkladovú DB.
To nie je zlé vychodisko. Čím menej od DB čakáš, tým lepšie môžeš v budúcnosti škálovať.
To bol skor prijemny bonus a dnes standard.
Tu je to myslené tak, že máš ORM definíciu a nevráti ti jeden objekt, ale objektový strom podľa ORM špecifikácie.
To viem, ale stale je to stringovanie.
Keď od začiatku vieš, že to má bežať na týchto DB, tak je to súčasť špecifikácie. Je rozdiel od sľubu, že s ORM môžete kedykoľvek zmeniť podkladovú DB.
Ano, ale ja som ORM nikdy nebral tak, ze to ma bezat na akejkolvek databaze. Skor, ze ked pisem aplikciu dokazem to lahko naportovat na isty pocet databaz, ktore maju potrebne vlastnosti. Proste akakolvek ina abstrakcia.
V niecom je taky Doctrine dobry, v niecom nie. Napriklad take nativne ENUMs su docela pain in the ass… Je to dan za abstrakciu pre DB, ktore ENUM nemaju…
Ma vlastne PHP enum?