Nette\Database: představení

redhead napsal(a):

A to je přesně to, proč jsem zprvu nad NotORM kroutil hlavou. Mít takéto konstrukce v šabloně mi přijde velmi protivné. Vlastně se nemůže ani říct, že jde o model. Chudák kodér, aby si pamatoval celou databázi.

To se mi moc nezdá co píšete, však vám nikdo nebrání udělat si modely s metodami, které budou získávat potřebné data a potom prostřednictvím Presenteru je servírovat kodérovi. Ten stejně musí minimálně znát strukturu dat, které má vykreslit ve View.

Obecně si ale myslím, že není dobré ve View přímo vykonávat příkazy nad DatabaseConnectorem však to má být práce modelu a ani mě nenapadá jak by se řešilo cachování.

Osobně bych ukázku s možností využití notORM ve View klidně nechal, ale striktně upozornil začátečníky atd., že není dobré mastit dotazy nad databází do View vrstvy, protože si to neuvědomí.

Nebo se pletu?

Bohužel ORM by bylo zase v tom lepší, že by získalo všechny výsledky i pro vazby 1:1, 1:n, M:N a poskytlo mi array s objekty záznamů nebo array jak je v CakePHP. Takto si musím v modelu získané údaje zpracovat do rozumného formátu znovu do array.

Například:

<?php
                $applicationsArray = array();
                foreach (Model::$database->table('application')->order('title') as $application)
                {
                    echo $application->title, ' (', $application->author->name, ')';
                        $tagsApplicationArray = array();
                        foreach ($application->related('application_tag') as $application_tag) {
                                $tagsArray[] = $application_tag->tag;
                        }
                         $applicationsArray[] = array('app'=>$application,'tags'=>$tagsArray);
                }

                $this->template->apps= $applicationsArray;
?>

Editoval Pitrsonek (30. 12. 2010 19:01)

Stále nesouhlasím s vašim názorem, sám popíráte co jste napsal: do komentu šablony se napíše co presenter posílá nebo si to dumpne. V tomto se přeci nic nezměnilo. David poskytl řešení pro přístup k DB a záznamům a na vás je v jakém formátu je pošlete kodérovi do view jestliže ho dřív zajímalo jak se data řadí tak ho to bude zajímat i teď a jste nucen ho o tom informovat. Moc nechápu vaše výtky.

redhead napsal(a):

Řazení dat snad neřeším v šabloně ale v presenteru, z kterého pošlu maximálně pole s nějakými určenými indexy (které uvedu v komentu). Ale aby kodér, přemýšlel jakou tabulku vlastně má joinovat a aplikovat řazení (jehož offset a počet záznamů budu nejspíš opět posílat z presenteru???). Bavím se teď o kódu šablony, co napsal David v prvním postu (o ničem jiném). To mi přijde opravdu zlé.

Asi si nerozumíme. Můžu si toto napsat do nějakých modelových tříd, ale pak vlastně dělám to samé, co jsem dělal s dibi a o žádnou nativní Nette modelovou vrstvu se nejedná. Pouze o jiný přístup k DB.

Edit: pokud ovšem David nechystá něco dalšího (z toho co psal, to tak vypadá). Jen ta šablona mě prostě dost zarazila. Toť vše.

Jo, já se v tom taky poněkud ztratil… Je pravda, že řazení a stránkování by model nemusel vůbec řešit (nebo ne přímo), ale aby se kvůli tomu muselo volat NotORM v šabloně? Proč není možné udělat nějakou abstraktní variantu DibiDataSource? Mohl by to třeba být interface, přes který by šablona nějak unifikovaně přistupovala k datům z Modelu

Editoval Teyras (30. 12. 2010 19:47)

Ok, beru, že to není hotový model, v tom případě by bylo dobré to neuvádět v šablonách, protože by si to mohl někdo špatně vyložit: https://forum.nette.org/…tte-database

Neboj, tohle už dávno chápu. Pokud je to tak a žádný nativní model nebude, tak se omlouvám, měl jsem za to, že něco takové hodláš spáchat a věta „jeden z pilířů chystané podpory modelu“ mě v tom jaksi utvrdila (bylo to myšleno jinak, teď to už vidím).

Honza: ja jsem docela nalomenej, pri nejblizsim jinem projektu to asi zkusim notORM zpusobem (ze DB de facto definuje velkou cast modelu a neni tam jen jako uloziste dat kam se to nejak naseka dle zvule ORM knihovny bez toho abych na to dohlizel). Myslim ze oba zpusoby maji sve svetle chvilky. :) (a taky asi nocni mury :))

@Ped:

Tak nevím jestli jsem tu opravdu jediný, komu se mít tohle v šabloně příčí, už jenom složitostí a délkou zápisu, já sám mám v aplikaci i 2–3 JOINy na jeden dotaz s ne zrovna lehkými ONy, to psát v každé šabloně, kde to potřebuju, tak se zblázním (navíc opakuju kód). Na druhou stranu, pokud bych chtěl použít Nette\Database v modelu, je tu ta obtíž, kterou popsal Pitrsonek v příspěvku #3. WOW efekt je opravdu naprosto úžasný, ale až praxe ukáže, jestli se to uchytí. Počkám si na další podpůrné třídy pro model a pak se uvidí.

Možná jo. Já tu celou dobu „kritizuju“ ukázku použití třídy Database v šabloně, která mi prostě přijde ujetá. A teď naposled jsem vyzdvihl to, co říkal Petrsonek v #3. O ničem jiném jsem tu nepsal. Tak mi to když tak vysvětlete :)

Davide napiš jim malý příkladek využití Database přímo v modelu a způsob předaní dat v šabloně a budeš mít svatý pokoj ;)

Klidně to můžeš (a podle mě by se mělo) dát do šablony již na filtrované a nastránkované. Což Nette\Database nebrání v tom, aby se to načetlo až v průběhu vykreslovní šablony.

Skalda napsal(a):

To súvisí s chybou v Nette\Database\Selector.

https://forum.nette.org/…ase-selector

https://forum.nette.org/…ckova-notace

1++ fetchAssoc

1++ fetchAll

Tieto veci by sa zišli v Nette\Database. fetchAssoc je killer fičura dibi a mohla by to byť killer fičura aj v Nette.

Editoval Cifro (20. 1. 2011 14:54)

bojovyletoun napsal(a):

• nevýhoda dibi = musím ošéfovat joiny

Nebral by som to ako nevýhodu v prípade ak chceš zostaviť iný dotaz s join ako to vytvára Nette\Database\Selector. Možno nevýhoda že ten join musíš v dibi napísať, v Nette\Database\Selector ti to zostaví samo. Napr. už spomínaný join a odvodená tabuľka.

V souvislosti s částečnou implementací NotORM v podobě Nette.Database jsem se chtěl zeptat, jestli je v plánu taktéž část modifikace/vkládání nových záznamů, případně jak se bude lišit syntaxe. Předem díky za odpověď.

+1

Jsem se musel zaregistrovat abych vyjadril podporu. :) Taky mi prijde ten priklad hodne spatny. Je to jen o neco hezci zapis dibi::query a mit takove veci v sablone… Prijde mi to temer jako anti-pattern co se tyce udrzovatelnosti kodu a vlastne i celeho systemu.

redhead napsal(a):

A to je přesně to, proč jsem zprvu nad NotORM kroutil hlavou. Mít takéto konstrukce v šabloně mi přijde velmi protivné. Vlastně se nemůže ani říct, že jde o model. Chudák kodér, aby si pamatoval celou databázi.

Jakube, joinovat subselecty pravděpodobně znamená:

SELECT *
FROM tabulka
INNER JOIN (
	SELECT * FROM tabulka2
	WHERE id = 5
) t2 USING (sloupec)

třeba

Myslel jsem toto:
Původně jsem měl toto: (že jsem musel 2× uvádět clovek_typ_id).

$cl = $this->dbx->table('clovek')->where('clovek_typ_id', $this->dbx->table('viewparam')->where('view_id', $view)->select('clovek_typ_id'));

Jestli by to šlo nějak přímočaře.

Tabulka pohledů (view), které obsahuje připravené výběry lidí podle jejich skupin. Popsáno zde
Co chci: začínám u nějakého view(třeba 10) a chci se dostat přes clovek_typ, které patří do daného view ke konkrétním lidím.

Jde to vyřešit nějak elegantně, abych tam nemusel hledat jména primárních klíčů? tj něco jako(pseudokod) table(view)->get(10)->clovek_typ()->clovek. Nebo jít inverzně: table('clovek')->where(clovek_typ in view 10)

Tedy shrnu dotaz:

Pokud, chci probublat přes několik tabulek (view->clovek_typ->clovek),
tak jak mám postupovat (náznak- vícenásobné reference jdou jen na odkazovanou tabluku)?

• začnout od tabulky s podmínkou `$db->table('view')->get(10)->...select(view.viewparam.clovek_typ.clovek)'
• začnout od tabulky s výsledkem $db->table('clovek')->where('clovek.clovek_typ.viewparam.view.id',10)

diagram:

Editoval bojovyletoun (21. 1. 2011 13:08)

bojovyletoun napsal(a):

Pokud, chci probublat přes několik tabulek (view->clovek_typ->clovek),
tak jak mám postupovat (náznak- vícenásobné reference jdou jen na odkazovanou tabluku)?

• začnout od tabulky s podmínkou `$db->table('view')->get(10)->...select(view.viewparam.clovek_typ.clovek)'
• začnout od tabulky s výsledkem $db->table('clovek')->where('clovek.clovek_typ.viewparam.view.id',10)

Neviem či toto konkrétne by neprinieslo skôr zmätok. Zápis „$table.$column“ sa v súčasnosti používa ako odkaz z tabuľky application_tag na tabuľku application a nie opačne. Jakub sa už viackrát vyjadril že pre odkaz z application na application_tag (tiež by som to rad využil) by musela vzniknúť nová syntax, zatiaľ sa nevie aká a tiež či to niekedy bude implementované.

Editoval dakota (21. 1. 2011 14:12)

Jakube, jsi si jistý, že myslíš ten samý fetchAssoc jako my? :)

$result = dibi::select('col1, col2, col3, col4')->from('tabulka');
$assoc = $result->fetchAssoc('col1[]col2|col3=col4');

foreach ($assoc as $col1 => $list1) {
	foreach ($list1 as $col2list) {
		foreach($col2list as $col2 => $col3list) {
			foreach ($col3list as $col3 => $col4) {
				echo $col4;
			}
		}
	}
}

možná jsem se v tom trochu zamotal, ale s fetchAssoc z dibi jsou dělat podobné prasečinky. Jsi si jistý že ekvivalentem je

iterator_to_array($result->fetch());

? :)

Mám další návrh ohledně referencí. Nyní jde pomocí through změnit sloupec, podle kterého se hledají odkazující řádky (tedy $user->related('article')->through('published_by)), ale jakto zařídit opačně : $article->related('user')->through?('published_by)

myslíte, že je to užitečné? Popř jak se toho docílí elegantně?

Příklad:

• table user: id, jmeno
• table article: id, text, user_id(ref:user.id), published_by(ref:user.id)

/* vypíše uživatele a články, které oni zveřejnili.
Pokud by tam through nebylo, tak by se vypsaly články, jejichž je autorem. */
echo "Publishers:".NL;
foreach ($db->table('user') as $u){
    echo $u->name.":".NL;
    foreach ($u->related('article')->through('published_by') as $a){
	echo "- ".$a->text.NL;
    }
}
echo "<hr>";
/* vypíše články a k nim toho uživatele, který článek zveřejnil.
Pokud by tam through nebylo, tak se vypíše uživatel, který autorem článku. */
echo NL."Articles and publishers?".NL;
foreach ($db->table('article') as $a){
    echo $a->text."-> user_id pomocí ref(user):".$a->ref('user')->through?("published_by")->name.NL;
}

Editoval bojovyletoun (23. 1. 2011 0:47)

bojovyletoun napsal(a):

potom to selže u TableRow:
Unknown column clovek_typ.jmeno,Unknown column clovek.jmeno

V NotORM jsem to předělal na číselnou pozici, díky za nahlášení.

Rychlym preletenim kodu (a dokumentacie) zistujem, ze Nette\Database nema moznost nastavenia vlastnych konvencii – plurary ako nazvy tabuliek, cudzie kluce a pod. NotORM tuto moznost ma a kedze som zvyknuty na mnozne cislo v nazvoch tabuliek, kcem sa opyat, ci sa nastavenie vlastnych konvencii planuje?

Tohle

{foreach $database->table('application')->order('title')->limit(5) as $application}
        <h2>{$application->title} ({$application->author->name})</h2>

        {foreach $application->related('application_tag') as $application_tag}
                {$application_tag->tag->name}{sep}, {/sep}
        {/foreach}
{/foreach}

je (sic) syntakticky hezký (ale) špageťák. Pevně věřím, že jsi tohle Davide psal jako vtip. IMO by se proměnná $database nikdy neměla dostat mimo model (do Controlleru a už proboha vůbec ne do View) a nějaké table()->order()->groupBy() by mělo zůstat za Mapperem.

Mam k reseni ohledne tohoto tematu dve veci.

Zadani asi takoveto: Mam tabulky typu %prefix%_tabulka a pouzivam klice typu id%tabulka%.
Chci-li vyuzit alespon castecne podpory a featur tridy Nette\Database, tak pouziju Reflection\DatabaseReflection k prepsani vychozich hodnot, ze kterych zjistuje primarni klic, nazev tabulky, atp.. Problem nastane ve chvili, kdy se dojde k dotazu.

Pouzivam stable verze nette 2.0, PHP 5.3

Napr. vytvarim spojeni do dtb v jakemsi BaseModelu, ktery dedi ostatni modely, obsahuje statickou promennou $database, ktera drzi soucasne spojeni do dtb.
Inicializace cca takto (:

<?php
public function init( $options ) {
	$conn = new Database\Connection($options->dsn, $options->user, $options->password);

	// trosku znasilneni, naprimo do objektu, ale setter jsem nenasel
	$ref = new Reflection\DatabaseReflection('id%s', null, 'PREFIX_%s');
	$conn->databaseReflection = $ref;

	self::$database;
}
?>

Nyni by melo byt znamo, ze chci aby byl primarni klic ve formatu „idTabulka“ a tabulky ve formatu „PREFIX_tabulka“.

Kdyz vsak provedu jakykoli dotaz, napr.

<?php
$database->table("zakaznik")->insert($data);
?>

tak se vznikne dotaz, ve kterem neni nazev tabulky nahrazen pozadovanou patternou, tj. PREFIX_tabulka, ale pouze tabulka.

Nestudoval jsem kod, jak presne DatabaseReflection funguje v celem kontextu, ale pokud tam muzu definovat pattern u primarniho klice, foregin klice, tak ocekavam ze to jde i u table.

--
Druha vec, co se tyce dotazu do dtb primo z sablony ci presenteru, tak imho to neni moudry napad. S dtb ma komunikovat pouze model, dotaz z view naprosto odporuje MVC/MVP, view zobrazuje data z modelu, takto je model obchazen. Navic to vnasi neporadek do sablon, kdezto v modelu jsou vsechny dotazy pohromade a pripadny update se provadi v ramci jednoho souboru (napr.) … v pripade upravy by to znamenalo projit vsechny sablony.

Editoval tygl (20. 2. 2011 18:14)