Databázová vrstva pro Nette: dibi, Doctrine, NotORM?

Na NotORM jsem koukal. Jakub se tam snaží trošku o obstrakci funkcí, v nichž se databázové engine odlišují (třeba LIMIT / OFFSET), ale není to dotaženo (něco málo dělá pro Oracle).

Druhým kritickým bodem je práce s datumem a časem, to má také každá DB jinak, takže pokud má mít layer smysl, chtělo by takové funkce doplnit.

Třetím bodem je „lastInsertId“ při INSERTu – v některých DB není klasický autoincrement a dělá se to jinak, třeba přes sekvence.

Čtvrtým bodem je ukládání velkého textu – CLOB, XML a další. Opět, v některých DB to není možné nacpat do běžného SQL dotazu.

Pátým bodem je fulltext. V každé DB se hledá jinak.

To není míněno jako kritika, jen pokud má mít layer smysl oproti přímému použití PDO, pak by aspoň těchto pár věcí navíc měl (IMHO) přinášet. Pokud by byl zájem, pro Oracle a SQL Server rád logiku doplním.

Editoval Radek Hulán (8. 12. 2010 17:44)

Osobně bych v Nette pro přístup k datům rád viděl nějaký obecný objekt na způsob DataSource a konkrétní řešení práce s databází ve stylu dibi… NotORM jsem ještě moc zblízka nezkoumal, takže nemůžu soudit. Doctrine se mi k Nette prostě nehodí, i když to je možná jen tím, že mi nevoní samo o sobě :) Hlavně ale moc nesouhlasím se zbytečným začleňováním cizích projektů, i když ta volba by tu zůstat měla…

Editoval Teyras (8. 12. 2010 19:02)

Jo, to jsem chtěl taky říct… Kdyby pro to byl nějakej na layeru/systému ukládání nezávislej způsob (nejspíš interface), klidně bych se s řazením a stránkováním v template sžil :)

Můžeš mít přece více instancí NotORM, tak jako máš více spojení v dibi, stejně neuděláš přenášení dat na úrovni SQL mezi dvěma spojeními, stejně budeš mít 2 připojení, NotORM je jenom rychlejší způsob jak data získat.

Co se týče komplexity, u jednoduchých věcí „kde byla abstrakce přítěží“ bych se naopak NotORM vůbec nebál, nesleduju jak dobře je na tom s opačným směrem (zápis), ale určitě je to použitelné při skombinování s dibi.

Což je další věc co jsem chtěl navrhnout. Udělat z NotORM šikovnější DataSource, napadlo mě to v souvislosti s tím co napsal David, takže ho to určitě napadlo už taky… Zkrátka začlenit NotORM do dibi, vedle nativních SQL, fluent a datasource.

Zpátky ke komplexitě… Co se týče velice, velice složitých věcí, je to jenom otázka návrhu, nemyslím si, že dobře navržená struktura entit ti bude ztěžovat získávání složitých struktur z databáze. Naopak.

Navíc (ono to sice platí i u čistého SQL, ale o to tady ještě víc) cokoliv napíšeš, nemusíš psát znovu, čím víc abstraktnější nástroj použiješ, tím míň pak budeš muset udělat úprav, když kód budeš chtít použít jinde.

Malý dodatek nakonec… Stejně přirozeným vývojem k abstrakci všichni dojdeme, já jsem došel už myslím docela daleko, když jsem se pustil do Doctrine. Jediné co vám všem v tom brání, jsou vlastní předsudky a nechuť zkoušet nové věci, protože stačí vyzkoušet něco nového a názor změníte, to jestli se se přikloníte k NotORM, nějakému ActiveRecord, nebo kanónu Doctrine2 je zase něco jiného.

asi trošku utíkáme od tématu takže pro zájemce, pokračování tady: http://nezmar.jabbim.cz/…0/12/09.html#… ;-)

Radek Hulán napsal(a):

To není míněno jako kritika, jen pokud má mít layer smysl oproti přímému použití PDO, pak by aspoň těchto pár věcí navíc měl (IMHO) přinášet. Pokud by byl zájem, pro Oracle a SQL Server rád logiku doplním.

Díky za nabídku, pomoc u těchto databázových systémů určitě ocením. NotORM nicméně chápu jako skládač dotazů, takže třeba podporou různých syntaxí fulltextu si nejsem jist. Do ostatních věcí se můžeš pustit ve forku na GitHubu.

No to mě hrábne… Nějaký čas se mořím s vlastní implementací a když to skoro je (rozuměj „před refactorem“), tak si tu přečtu, že to bude součástí FW :)
Moje řešení je postaveno jako ORM nadstavba nad dibi ala Doctrine2.
Takže si definuju entity přes anotace, nastavuji typ dat, jointy, subkolekce (objednávka->položky) atd. No a pak už se jen vytvoří Entity Manager a instancujou entity.
Dále mám navázane komponenty, kterým se předá Entita(kolekce) a vytvoří se control s tabulkou, včetně paginatoru a sub tabulky(tady vývoj zamrznul – potřebuju dynamické snippety :( ) nebo formulář s validací dat (bráno z definice entity). Data čtu až když jsou opravdu potřeba a ne při vytvoření entity, zabraňuje to vytváření duplicitních entit, optimalizace zápisu do db…
… Kdyby to někoho zajímalo, mohu se podělit.

Ono lidí, co si to řešili po svém, je asi spousta :) Myslím, že upnout to na github a poslat odkaz moc nestojí, a pokud je to kvalitní řešení nebo aspoň dobrej nápad, někdo si toho určitě všimne…

Rampa wrote:

No to mě hrábne… Nějaký čas se mořím s vlastní implementací a když to skoro je (rozuměj „před refactorem“), tak si tu přečtu, že to bude součástí FW :)
Moje řešení je postaveno jako ORM nadstavba nad dibi ala Doctrine2.
Takže si definuju entity přes anotace, nastavuji typ dat, jointy, subkolekce (objednávka->položky) atd. No a pak už se jen vytvoří Entity Manager a instancujou entity.
Dále mám navázane komponenty, kterým se předá Entita(kolekce) a vytvoří se control s tabulkou, včetně paginatoru a sub tabulky(tady vývoj zamrznul – potřebuju dynamické snippety :( ) nebo formulář s validací dat (bráno z definice entity). Data čtu až když jsou opravdu potřeba a ne při vytvoření entity, zabraňuje to vytváření duplicitních entit, optimalizace zápisu do db…
… Kdyby to někoho zajímalo, mohu se podělit.

určitě to hoď na github…

Základní implementaci mám hotovou, ale přemýšlím, jak finálně pojmenovat jednotlivé třídy. Názvy Row nebo Connection mi připadají příliš obecné, byť ve jmenném prostoru dávají smysl (Nette\Database\Row).

David Grudl napsal(a):

Základní implementaci mám hotovou, ale přemýšlím, jak finálně pojmenovat jednotlivé třídy. Názvy Row nebo Connection mi připadají příliš obecné, byť ve jmenném prostoru dávají smysl (Nette\Database\Row).

A o tom jsou jmenné prostory :)

mkoubik napsal(a):

Jak jde Nette\Database\Row dohromady s model !== databázová tabulka? Nebo jsem mimo a moc si toho domýšlím?

Pri používaní dibi máš DibiRow kľudne aj ako JOIN viacerých tabuliek. A vystupuje to ako jeden riadok. To isté s Datagridom ;)

takze pre DB systemy bez PDO podpory nepouzitelne (napr. Ingres) …

@David: „Nette\Database není plnohodnotnou náhradou“

znamená to, že bude nutné na specifické věci používat Dibi nebo něco jiného? (pokud ano, znamenalo by to v případě non-PDO řešení duplicitní spojení k databázi a možné problémy s transakcemi)

paranoiq napsal(a):

stejně jako sis mohl napsat vlastní DibiIngresDriver, můžeš si napsat i vlastní PDO ovladač (a nemusí to být v céčku!). stačí napsat vlastní rozšíření tříd PDO a PDOStatement

Nemyslím si, že bude treba: http://community.ingres.com/wiki/PDO_Ingres.

@JAM3SoN, @Jan Tvrdík:

Myslím, že @mkoubik měl na mysli entitu. Třída řádek evokuje paralelu s řádkem relační DB, byť by to bylo více JOINů, entita naopak může obsahovat další entity (tedy něco, co si pod pojmem řádek jen těžko představit).

Čili k zamyšlení: pokud je do budoucna v plánu persistence objektů a data-mapper, pojmenování entita by mohlo charakter té třídy vystihovat lépe než pojmenování řádek.

JAM3SoN napsal(a):
Nemyslím si, že bude treba: http://community.ingres.com/wiki/PDO_Ingres.

to som nasiel ale mal som s tym davnejsie problemy pri rozbiehani a vyvoj je co som to kontroloval nijaky uz niekolko rokov …

paranoiq napsal(a):
stejně jako sis mohl napsat vlastní DibiIngresDriver, můžeš si napsat i vlastní PDO ovladač (a nemusí to být v céčku!). stačí napsat vlastní rozšíření tříd PDO a PDOStatement

mno ak to bude az take jednoduche tak potom (snad) v poho

Je to řešit například takhle. No, je to trošku škrabání se levou rukou kdo ví kde… Vestavěná podpora pro prefixy by se určitě hodila.

Ondřej Mirtes wrote:

Já nějak nechápu, proč aktuální Nette\Database !== dibi, ale něco nového a bez té příjemné dibi syntaxe, DibiFluent a dalších.

+1

@Oggy:
Máš ukážkový kód ako to používaš? NotORM mám prečítanú dokumentáciu, ale aktuálne si neviem predstaviť ako by som príklad nižšie napojil na Latte šablóny. Podľa príkladu tu: http://zdrojak.root.cz/…ne-s-notorm/#…, konkrétne táto časť:

<?php
foreach ($products as $product) {
    echo "<h3>" . htmlspecialchars($product["name"]) . "</h3>\n";
    list($suppliers) = $product->product_supplier()->aggregation("COUNT(*)");
    echo "<p>Cena: $product[price] Kč, dodavatelů: $suppliers</p>\n";
}
?>

Ako pretransformujem ten agregačný dotaz do latte?
Chcel by som mať niečo takéto:

<?php
{foreach $produkty as $produkt}
	<h3>{$produkt["name"]}</h3>
	{$produkt_suppliers}
{/foreach}
?>

.. alebo bez agregácie:

<?php
{foreach $produkty as $produkt}
	<h3>{$produkt["name"]}</h3>
	{if count($produkt_suppliers)>0}
		<ul>
		{foreach $produkt_suppliers as $supplier}
		<li>{$supplier["name"]}</li>
		{/foreach}
		</ul>
	{/if}
{/foreach}
?>

.. teda neviem ako sa zbaviť toho list(..) v šablóne. Nie je to tam pekné a radšej by som v render* naplnil $products a možno nejako $suppliers.

JAM3SoN napsal(a):

Ako pretransformujem ten agregačný dotaz do latte?
Chcel by som mať niečo takéto:

<?php
{foreach $produkty as $produkt}
	<h3>{$produkt["name"]}</h3>
	{$produkt_suppliers}
{/foreach}
?>

tady myslím že musí být něco jako..

<?php
{$produkt->produkt_suppliers()}
?>

Editoval Oggy (15. 12. 2010 15:37)

Veľmi pekne dakujem obom! Zjavne jeden z dvoch osobných projektov prepíšem z Doctriny do NotORM, nech mám čo porovnávať :)

Tharos napsal(a):

Jakube, nestálo by za to někde více demonstrovat možnosti NotORMu při použití s Nette?

Já se také přikláním k prosbě o nějaký tutoriál na použití spolu s Nette ..
A třeba i na nějaké méně používáné příkazy.. na hromadný insert, využítí při transakci apod.

Editoval Oggy (15. 12. 2010 16:24)

Oggy napsal(a):

Já se také přikláním k prosbě o nějaký tutoriál na použití spolu s Nette ..
A třeba i na nějaké méně používáné příkazy.. na hromadný insert, využítí při transakci apod.

Podporu hromadného insertu jsem nedávno přidal přes NotORM_Result::insert($row1, $row2, ...). Na transakce žádná obálka není, ty je potřeba volat přímo přes PDO.