ORM z druhé strany

Školení, která pořádám

Martin Malý píše o tom, co mu vadí na ORM (především nutnost synchronizace mezi kódem a databází) a nepřesně mě zmiňuje:

Chvíli jsem přemýšlel o řešení Jakuba Vrány, který si, jestli se dobře pamatuju, parsuje SQL a z něj si generuje strukturu pro třídu, ale furt se mi to zdálo příliš složité.

Já se ve svých myšlenkách (žádné ORM jsem nenapsal ani nepíšu) ubírám jiným směrem. Jde o to, že v kódu vůbec žádný seznam polí v jednotlivých tabulkách být nemusí. K čemu by mi tam vlastně měl být?

  1. Když uvedu neexistující název sloupce, tak se o tom dozvím v momentě, kdy se do databáze posílá sestavený dotaz nebo když se přistupuje k neexistující vlastnosti. To je sice o maličko později než když bych měl seznam sloupců k dispozici, ale je to ve stejné fázi (konkrétně při spuštění kódu, protože při kompilaci PHP přístup k neexistujícím vlastnostem nijak neověřuje).
  2. Datové typy mě prakticky nemusí zajímat, data mohu ošetřovat podle jejich PHP typu. Když třeba přešvihnu délku řetězce nebo pošlu NULL do NOT NULL sloupce, tak se o tom opět dozvím chybou nebo varováním databáze.
  3. Hlavním motivem tak může být to, aby IDE napovídalo názvy sloupců při práci s objektem. To ale řešíme problém IDE a nikoliv kódu, takže bych to raději řešil na úrovni IDE. Jistě by šel alespoň do některých IDE dopsat plugin, který by třeba při anotaci @table dokázal seznam vlastností načíst ze struktury tabulky.

Stručně řečeno: Bez seznamu sloupců v kódu se dá bez problémů obejít, takže synchronizaci mezi kódem a databází nemusíme vůbec řešit. Když bych informace o sloupcích mermomocí chtěl (třeba kvůli včasnější kontrole), tak bych je spíše získával reflexí (SHOW COLUMNS) při spuštění.

Jakub Vrána, Dobře míněné rady, 6.1.2010, diskuse: 8 (nové: 0)

Diskuse

Tom:

a "diky" zakazanym komentarum na misantropovi se musi reakce, ktere by se hodily do diskuze k clanku, trousit po X dalsich blozich :(

ikona Jakub Vrána OpenID:

Taky mi to přišlo trochu líto. Na druhou stranu v začátcích blogování to bylo úplně normální. Navíc napsání příspěvku na blog chce trochu víc pečlivosti než napsání komentáře, takže myšlenka pak není tak zkratkovitá.

Martin Malý:

Přesně tak. Vidíte, oč je takováhle reakce přínosnější, ucelenější a smysluplnější (navíc na dobrém místě), než utopený výkřik někde v haldě komentářů?

Tomáš Kafka:

Nestálo by teď za to doplnit pro čtenáře kteří sledují jen jednoho z vás chybějící článek - odkaz z misantropa na vybrané relevantní články jinde? Takové manuální trackbacky :)

Martin Malý:

K článku se nehodí žádný komentář. Děkuji za pochopení.

já:

Synchronizace mezi kódem a databází není přece třeba řešit u ORMu nikdy. Buď se kód sám "upravuje" podle databáze nebo tradičněji databáze "sama" podle návrhu kódu (Propel, Doctrine).

ikona Petr Kozelek:

Doporučuju prostudovat si projekty jako Hibernate v Javě a jeho klon NHibernate v .Net, které problematiku ORM řeší velmi komplexně. Navíc už jsou docela staré a mají početnou komunitu, takže už si dávno prošly porodními bolestmi začínajících frameworků.

Martin Malý:

Já vím že to není přesné. Já si vzpomněl na tvůj nástroj pro generování adminských rozhraní, cos předváděl na té konferenci s Vilémem Málkem (zapomínám jak se jmenovala). A vybavilo se mi, jak sis lehce rozšířil SQL a uložil si nějaké informace o vazbách do SQL komentářů, a z toho jsi pak generoval to adminské rozhraní. Pokud jsi to během těch let změnil, tak se omlouvám.

Diskuse je zrušena z důvodu spamu.

avatar © 2005-2024 Jakub Vrána. Publikované texty můžete přetiskovat pouze se svolením autora. Ukázky kódu smíte používat s uvedením autora a URL tohoto webu bez dalších omezení Creative Commons. Můžeme si tykat. Skripty předpokládají nastavení: magic_quotes_gpc=Off, magic_quotes_runtime=Off, error_reporting=E_ALL & ~E_NOTICE a očekávají předchozí zavolání mysql_set_charset. Skripty by měly být funkční v PHP >= 4.3 a PHP >= 5.0.