Komentáře k článku

Doctrine 2: základní definice entit

V úvodním článku seriálu jsme si systém Doctrine 2 obecně představili, ukázali si, kde jej stáhnout a jak jej nainstalovat. Dneska se pustíme do skutečné práce, řekneme si, co jsou vlastně entity a jak se s nimi v Doctrine 2 pracuje. Téma nám vydrží až do příště.

Zpět na článek

25 komentářů k článku Doctrine 2: základní definice entit:

  1. blizzboz

    otázka

    Keď už pracujeme s objektami, neni lepšie použiť nejakú objektovú databázu? Ja sám používam ORM (Entity Framework) ale ajtak nerozumiem v čom je použitie RDBMS + ORM frameworku lepšie ako priamo použitie ODBMS?

    1. drevolution

      Re: otázka
      Na tuto otázku není vůbec jednoduchá odpověď. Sám za sebe tvrdím, že pokud máme objektový model, tak určitě není automatické, že ho budeme ukládat do objektové databáze. Já osobně sahám po relační databázi z těchto důvodů:

      1. Větší zkušenost a více znalostí relačních databází
      2. Jednoduchost na správu a dostupnost (i když ta jednoduchost pramení právě z větších znalostí)
      3. Možnost dekompozice objektů do relací. Často je to nevýhoda, ale občas to může být výhoda

      Určitě jsem na něco ještě zapomněl, ale jen tyto důvody mě drží u relačních databází. Pokud máme dobré ORM, což Doctrine 2 s přivřeným okem je, je rozhodování ještě jednodušší.

  2. Vrtak-CZ

    BUG v ukázce

    v ukázce ukládání článků se uloží jenom první… Protože ten druhý není přidán do UnitOfWorku schází tam $entityManager->persist($anotherArticle); před flush.

    1. Ondrej Mirtes

      Re: BUG v ukázce

      Je to takhle spravne, na entite se vola persist jen jednou, pak uz se ulozi jen pomoci flush().

    2. Jan TichýAutor příspěvku

      Re: BUG v ukázce

      Je to skutečně tak, jak píše Ondra výše – persist() se musí volat jen na úplně nově vytvořené entity. Od toho okamžiku už je entita trvale pod dohledem EntityManageru, a to i pokud ji získáme v nějakém jiném requestu přes find(). Takže při jakékoliv další změně se už nemusí persist() volat, EntityManager sám automaticky zajistí, že se všechny provedené změny zařadí do fronty v UnitOfWork a při nejbližším zavolání flush() pak trvale uloží i do databáze. Tak je tomu až do té doby, než entitu smažu či odepnu z EntityManageru.

      Každopádně podrobnější debatu nad fungováním EntityManageru a UnitOfWork navrhuji nechat až pod článek, který se jimi bude zabývat podrobněji.

      1. juzna

        Efeknivnost

        Jak Doctrine pozna, ktere zaznamy se zmenily a tzn. ktere musi ulozit do DB?
        Jde mi o to, ze treba nactu tisic zaznamu pomoci find(), na par z nich udelam nejakou malou zmenu a pak zavolam flush(). Bude Doctrine fungovat efektivne?
        A jeste by me zajimalo, je mozne udelat nejaky hook, aby mi Doctrine logovalo veskere provedene zmeny (kdo, kdy, puvodni data, nova data)?
        Diky za rady

        1. drevolution

          Re: Efeknivnost

          Jak Doctrine pozna, ktere zaznamy se zmenily a tzn. ktere musi ulozit do DB? Jde mi o to, ze treba nactu tisic zaznamu pomoci find(), na par z nich udelam nejakou malou zmenu a pak zavolam flush(). Bude Doctrine fungovat efektivne?

          V rámci možností to efektivně funguje. Začíná to již při načítání entit. Pro každou načítanou entitu se pomocí funkce spl_object_hash() spočítá hash, který se uloží do interního pole v Unit of Work. Jakmile zavoláme flush na Entity Manageru, zavolá Entity Manager Unit of Work, aby zařídil uložení dat. Unit of Work projde každou načtenou entitu, spočítá pro ní další hash a porovná ho s hodnotou uloženou při načtení entity. Pokud se hodnoty nerovnají, ví, že se entita změnila. Aby byla práce ještě efektivnější, počítá si ještě pro každou entitu set změn, které pak pošle do databáze (což opět nejakým způsobem opimalizuje).

          A jeste by me zajimalo, je mozne udelat nejaky hook, aby mi Doctrine logovalo veskere provedene zmeny (kdo, kdy, puvodni data, nova data)?

          Toto udělat lze. V Doctrine2 se to realizuje pomocí listenerů. Honza jim určitě v některém díle bude věnovat pozornost, takže sem dám pouze odkaz do dokumentace: http://www.doctrine-project.org/projects/orm/2.0/docs/reference/events/en#implementing-event-listeners

          Některé další implementace listenerů pak ukázal Benjamin Eberlei na Doctrine blogu:

          1. paranoiq

            Re: spl_object_hash() není hash!

            spl_object_hash() není hash! tato funkce nic nepočítá. pouze vrací jednoznačný identifikátor objektu. při změně vlastností objektu se hodnota vrácená spl_object_hash() nemění.
            tato hodnota je použita pouze k indexaci polí entit a polí původních hodnot, aby je bylo možné navzájem dohledat a porovnat i pokud dojde ke změně všech údajů entity
            _______
            porovnávat entity s původní hodnotou musí složitěji (u private a protected nejspíš pomocí odemykání metodou setAccessible() z Reflection nebo konverzí objektu na pole)

      2. Vrtak-CZ

        Re: BUG v ukázce

        Ha super já to pro jistotu vždy explicitně persistoval. A navíc jsem díky tomu konečně pochopil smysl  $em->detach($entity);

  3. drevolution

    Dobrý článek

    Dobrý článek Honzo. Hlavně úvod se mi líbí, protože lehce přesahuje tématiku ORM a ukazuje přístup, jak stavět doménové objekty, které jsou izolované od persistentní vrstvy aplikace.

  4. jos

    myšlenkový posun

    Typickým příkladem jsou cizí klíče. Ve skutečném světě nic takového jako cizí klíč není. Článek je prostě zařazen do nějaké kategorie. To, že se to v relačních databázích řeší nějakým cizím klíčem category_id v tabulce article, je jenom vedlejší efekt toho, jak relační databáze fungují.

    Asi by se slušelo říct, že je to kvůli referenční integritě a že to programátor dělá hlavně proto, aby mu databáze nelhala (protože tam strčil / nechal strčit nesmysly). To s tim vedlejším efektem sem buď nepochopil, nebo je to úplnej nesmysl.
    Nevim o SQL databázi, která by mi zakázala joinovat přes atributy jen proto, že mezi nima není cizí klíč

    Jinak k tomu myšlenkovýmu posunu – programátor by se měl v případě cizích klíčů posunout spíš k uvažování o „doméně“ atributu relace. Mějme relaci A s atributem FOO (jehož hodnoty jsou z množiny přirozených čísel) a v ní dva řádky s hodnotama 1 a 2. Dále mějme relaci B s atributem BAR o němž prohlásíme, že je z domény (je datovýho typu) A.FOO a o přirozených číslech se v tomhle případě dále nebavíme

    Bohužel současný produkty nenabízejí takhle přímočarý vyjádření … (nebo jo?)

    A vůbec všechny SQL databáze dělají z programátora otroka a Doctrine mi nepřipadá jako elegantní způsob jak se z toho vymanit

    1. Jan TichýAutor příspěvku

      Re: myšlenkový posun

      Asi by se slušelo říct, že je to kvůli referenční integritě a že to programátor dělá hlavně proto, aby mu databáze nelhala (protože tam strčil / nechal strčit nesmysly).

      Snažil jsem se tím říct víceméně to samé, co pak o něco dále píšete sám. Prostě v relačních databázích musím explicitně evidovat, přiřazovat a číst ID odkazovaného záznamu, takže článek přiřadím do kategorie číslo 3 tak, že přiřadím  article.category_id = 3.

      Což je ale úplně špatné vnímání pokřivené specifiky relačních databází. Při práci s Doctrine 2 je potřeba právě myslet doménově a nezatěžovat se nějakými cizíma IDčkama. Takže přiřazení článku do kategorie se děje (schematicky vyjádřeno) napřiklad jako article.category = category, případně category.articles[] = article. Prostě žádná IDčka, žádné cizí klíče, nic takového.

      1. Vrtak-CZ

        Re: myšlenkový posun

        Tohle chápu a líbí se mi. Ale jak řešíš právě avizovaný případ přiřazení kategorie k článku. Mám selectbox a se seznamem kategorií a jako nejvhodnější mě připadá pro value použít ID kategorie. Jenže pak obcházím právě onu Doménovou logiku (nebo mě to tak alespoň připadá).

        1. Jan TichýAutor příspěvku

          Re: myšlenkový posun

          Mícháš tu dohromady model a view. Na straně modelu se žádná doménová logika neobchází, protože prostě uděláš $article->setCategory($category) respektive $category->addArticle($article) a je to naprosto čisté.

          Jiná věc jsou samozřejmě selectboxy, do kterých musíš cpát nějaké skalární veličiny, které jsou schopné mi jednoznačně identifikovat danou kategorii, a pro ten případ se pak samozřejmě hodí nejlépe IDčko. A pak po odeslání formuláře se samozřejmě v controlleru/pre­senteru udělá něco jako $article = $em->find('Article', $articleId); $category = $em->find('Category', $categoryId);. Ale to se děje ze specifických důvodů a někde úplně jinde, než v modelu – tedy ve view a controlleru/pre­senteru. Model je prostě i nadále čistě doménový.

          1. juzna

            Re: myšlenkový posun

            Doctrine cloveka nuti nejdriv ta data vytahnout z databaze, a pak tam zapsat upravu. Takze na takovou jednoduchou cinnost ti driv stacil jeden update, ale kluvi Doctrine se budou muset udelat jeste 2 selecty.
            Toto se mi zda takove „divne“ a porad mi to nejde do hlavy. A navic se bojim poklesu vykonu aplikace kvuli takovymto zbytecnym operacim. Odhaduju, ze to ale zase nebude az takovy problem, ze?

            1. drevolution

              Re: myšlenkový posun

              Výkonový pokles tu samozřejmě je. To není problém jen Doctrine2, ale jakéhokoliv ORM. ORM se na oplátku snaží poskytnou komfort v mapování.

              Nicméně je zde možnost, jak nenatahovat všechny entity, ale napsat si UPDATE ručně. Nepoužívá se na to čisté SQL, nýbrž DQL (Doctrine Query Language), které stále pracuje s entitami a jejich atributy. Takováhle aktualizace skrz DQL může být pak vložena do vlastního repozitáře konkrétní entity (např. nějaký ArticleRepository), který bude mít kupříkladu metodu ArticleReposi­tory::acceptA­llArticlesByDa­te(DateTime $date).

              Jak se píše UPDATE v DQL je v dokumentaci v sekci UPDATE queries

              1. Pavel

                Re: myšlenkový posun

                Nešlo by vytvořit neúplný objekt Article, který by se teprve při přístupu k jeho atributům inicializoval? Tuším by to mohl být návrhový vzor Decorator.

                1. Jan TichýAutor příspěvku

                  Re: myšlenkový posun

                  Rozhodně šlo. V Doctrine 2 se takovým neúplným objektům říká proxy a jsou využívané právě pro pozdní načítání dat jednotlivých entit. Určitě se k nim ještě v některém z příštích dílů seriálu podrobněji dostaneme.

  5. Vrtak-CZ

    NEescapovaní názvů entity (tabulky) a sloupců

    Já vím že celkem spamuju ale…
    Na to neescapování jsem nadával cca před týdnem. Vůbec to nechápu ale je k tomu tady ISSUE kterou jsem taky nepochopil. Nicméně myslím si že pokud se „zbouří“ dostatek lidí mohlo by to „borce“ od Doctrine donutit to vyřešit lépe…

  6. srigi

    sklamanie

    Po precitani clanku musim napisat, ze som z Doctrine 2 sklamany. V snippetoch vidim nenormalne velku zavislost medzi Entitou a (sry za anglictinu) underlaying storage engine. A z tejto debaty medzi autorom clanku a developerom Doctrine 2 som sklamany este viac.
    Dufal som, ze Doctrine 2 sa priblizi k 5-lay Modelu, ktory uz pan Tichy popisal v dnes uz pomaly kultovom clanku u seba na blogu. Dufal som, ze Doctrine 2 mi umozni napisat domenove modely (Entity) a iba pomocou vymeny jednej triedy kdesi v 4–5 vrstve zmenit engine z MySQL na MongoDB. Je mi jasne, ze toto naprogramovat je skoro nemozne, ale ze bude Doctrine tak daleko od tohoto sna som necakal.

    1. drevolution

      Re: sklamanie

      Já z té debaty vůbec zklamaný nejsem. Mně pomohla uvědomit si, že to s quotováním není vůbec tak samozřejmá a jednoduchá záležitost, jak jsem si původně myslel.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3293