Jakub Kulhan dával na Twitteru odkaz na slajdy o nejlepší praktikách v Doctrine. Protože se o práci s databází zajímám, slajdy jsem si prošel. Některé praktiky mi přijdou dobré, některé věci bych řešil jinak. Určitě si projděte i ty slajdy, já reaguju jen na to, co mě dovedlo k zamyšlení.
Proč je Raspberry Pi skvělá věc na proof of concept, ale ne na nic dalšího, jak vyrobit nejlepší 3D tiskárnu na světě, jak si zprasit kód nebo postavit letadlo. V sobotu si někteří z nás zajeli namísto Letné kousek dál do Dejvic na konferenci Devel.cz.
React s verzí 16.8 přináší zásadní novinku, a tou jsou Hooks, které mají přinést řešení pro hned 3 největší problémy, se kterými se v Reactu potýkáme. Implementace komponent pomocí tříd, sdílení logiky, nepraktický způsob práce s životním cyklem komponent. Představíme vám React Hooks a na konci ukážeme funkční příklad.
Pojednání o tom, jak (ne)obtížné je začít pracovat jako vývojář a jakou cestu očekávat. Není v něm ani jedna ukázka kódu, ale je v něm pár odborných pojmů. Pro lidi, kteří zvažují se naučit kódit/vyvíjet/programovat a pro ty, které jen zajímá, jak taková cesta vypadá.
ORM, FP, skalovanie...
Zaujimavy pohlad na vec z pohladu cloveka, ktory preferuje FP. Neviem ci je vsak korektne takto pisat o ORM, kedze neboli vyzdvihnute realne problemy ORM, iba alternativne moznosti bez pouzitia ORM. Nevadi :)
K vete o presune logiky z DB do kodu a o skalovani, ktore v Cechach nikto nepotrebuje – tuto nesuhlasim, presun logiky z DB do kodu uz na zaciatku je najlahsia cesta k tomu, aby sa neskor skalovalo, ak to bude potrebne. A ak ta potreba pride, tak databaza zostane uzkym hrdlom a cela aplikacia sa bude moct zahodit a napisat na novo, pripadne bude potrebne celkom velmi zrefaktorovat jadro. Technickemu dlhu nikto neutecie :) Aj na mensom Slovensku sme si mysleli, ze skalovat nebude treba a zrazu mame takmer 2TB velku databazu ;)
Re: ORM, FP, skalovanie...
Jasně, já třeba funguji tak, že píšu třeba i pokročilá SQLka, ale nemám logiku vůbec v databázi. Takže třeba mám Common Table Expressions, views, ale nemám stored procedury. Vnímám to jako dobrý kompromis mezi praktičností a čistotou. U megaprojektu by mě to možná nutilo udělat té abstrakce víc.
Díky za jiný pohled na věc, ale zdá se mi, že si trochu zapomněl, že se to týká pouze Doctrine ORM.
Doporučuju záznam celé přednášky, který je přínosnější než samotné slajdy
https://vimeo.com/channels/phpday/134178140
The database is just saving things
Doctrine ORM se snaží být nezávislá na typu DB (MySQL, Postgre, atd..). Doctrine ORM se snaží být „database agnostic“. Pokud využiješ naplno potenciál dané DB (triggery, views, procedury), přijdeš o možnost, bez úpravy kódu, přejít na jinou DB. Jednoduše proto, že daná DB např. triggery vůbec nepodporuje.
Jasně, v reálném světe se moc často nestává, že se přechází na jinou DB. Doctrine umožňuje jednoduché přepnutí DB, proto je databáze jako hloupé uložiště „best practice“. Možnost úpravou jednoho řádku přepnout aplikaci z MySQL na SQLite se někdy hodí.
Entities should work without db
Závislostí na DB je zde myšleno např. generování ID entity pomocí auto_increment indexu v DB, kdy entita nemá žádné ID dokud neproběhne uložení do databáze a nelze s ní tak dále pracovat. Generovat UUID v konstruktoru entity místo použití auto_increment je tedy vhodnější a není potřeba komunikace s DB.
Design entities first
Řekl bych, že toto spíš vychází z toho jak celá Doctrine funguje. Jednoduše si nadefinuješ entity a jedním příkazem vytvoříš celou databázi. Databáze je díky tomu pouhým implementačním detailem a je jedno jakou nakonec zvolíš (viz. předchozí bod).
Avoid soft deletes
V tomhle naprosto souhlasím, oba způsoby jsou vhodné na něco jiného a většinou je implementace Event sourcingu o tolik složitější, že se od toho prostě upustí.
Keep collections hidden in your entities
Zase to vychází z toho, jakým způsobem funguje celé mapování. Kolekce si klidně z entit vracet můžeš, ale pouze jako nový objekt nebo jako immutabilní. V dokumentaci se doporučuje toArrray() a je to jen kvůli tomu, že doctrine kolekce nejsou immutabilní a jakýkoliv vnější kód může kolekci jakkoliv měnit (může se stát nevalidní). Změny se pak při uložení entity, z které byla kolekce předána projeví i v DB (pokud není namapováno jinak). Entita tak nemá žádnou kontrolu nad stavem kolekce, kterou si předal ven.
Pokud potřebuješ upravovat kolekci vně entity, můžeš ji po úpravě vždy entitě nastavit setterem.
Všechno jsou to doporučení a né dogma. Každé doporučení má své „ale“ a vždy bude záviset na konkrétním případu. Tvůj způsob použití může být „krátký, udržovatelný, velmi výkonný“, ale cílem těchto best practices není „krátký, udržovatelný, velmi výkonný“ kód, ale co nejvíc bezproblémové a pro většinu případu nejjednodušší použití celé Doctrine. Best practices pro „krátký, udržovatelný, velmi výkonný“ kód by určitě vypadaly jinak a asi obsahovaly hodně z toho co píšeš.
Re: The database is just saving things
Zcela souhlasím, pro normální provoz používáme MySQL, systémové testy pouštíme kvůli rychlosti na SQLite a začínáme pošilhávat po PostgreSQL (kvůli práci s jsony). Díky Doctrine tento přechod nejen bude možný, ale bude i zdarma.
Re: The database is just saving things
Pouzivat v produkci MySQL a na testy SQLite mi neprijde dlouhodobe jako dobrej napad, ty testy pak maji polovicni hodnotu. Lepsi je zlepsit nastaveni DB pro testy, nebo jejich spousteni paralelizovat. Ziskate tak i spolehlive testy pro upgrady DB na novejsi verze.
A jestli je pro vas nejvetsi motivace pro prechod na Postgres JSON, zkuste JSON implementaci v MySQL 5.7
Z jaké verze MySQL přechod zvažujete? V MySQL 5.7 už nativní podpora pro JSON je.