Manuální přidání databáze do debugbaru

Především kvůli rozdělení modelu do několika vrstev (Dao, Manager,…) přičemž jsem DB potřeboval až v nejnížší vrstvě. Dále pak kvůli přehlednosti – service jsem nedefinoval v configu, jelikož jsem ještě neznal přístupy do DB, ale až později a navíc jsem připojení k DB používal ve vlastních knihovnách a ne jen v modelu. A také kvuli nešeptávači v Netbeans:), což by možná šlo vyřešit komentářem, ale musel bych ho psát nad každou proměnnou reprezentující DB.

Z vrstev prozatím sešlo, takže bych to mohl vrátit na používání service, ale tak jak to mám teď mi to příjde přehlednější a obecnější, jen mám problém s tím debuggerem. Takže kdyby někdo věděl, jak to vyřešit bez použití service, byl bych moc rád. Pokud to nepůjde, budu muset nejspíš service použít, jelikož debugger je pro mě velká přidaná hodnota.

Editoval Swed (12. 5. 2012 20:48)

OK, asi se tedy přizpůsobím filozofii Nette, i když je mi proti srsti příjmout, že pokud bych uvažoval o modelu, který má například 5 vrstev, tak bych připojení k databázi předával přes všechny vrstvy (ve kterých připojení vůbec nepotřebuji). To mi příjde šílené, ale pokud chápu správně, tak přizpůsobit se filosofii Nette znamená o takovém modelu ani neuvažovat a držet se toho, jak je to vymyšlené původně. K základní adresářové struktuře Nette projektu se už asi nevrátím:) (mám jednu administraci pro mnoho projektů a potřebuji v tom mít pořádek), ale budu se snažit se méně odlišovat:) Díky za názor, který mě trochu navrátil do reality. Občas je asi potřeba trochu přistřihnout křídla.

Nemohl. Jak jsem již říkal, problém je v tom, že ve chvíli, kdy načítám config.neon, ještě neznám přístupy do DB daného projektu. Ty zjistím až později podle toho, o jaký projekt se jedná.

Nevadí, vrstvy už jsem vzdal. Není to při jednoduchosti tohoto systému potřeba. Horší problém je ten našeptávač v Netbeans (Další z problémů proč jsem zanevřel na service). Nemáš nějaký nápad, jak donutit prostředí, aby napovídalo metody u proměnné reprezentující service? Je to pro mě dost důležité. Pracuji na několika projektech a u každého na jiném frameworku a pamatovat si syntaxi každého z nich je nemožné.

Zkoušel jsem použít komentář a to nepomáhá:

<?php
	/** @var Nette\Database\Connection $Db */
	$Db = $Container->getService('db');
	$Db->...
?>

Způsob, kterým jsem to měl předtím, byl výhodný právě v tom, že prostředí vědělo, jaký objekt se v proměnné nachází a napovídalo mi jeho metody atd.

To je moc dobrý nápad! Ale funguje mi to bohužel jen pro service nadefinované v config.neon. Pro service definované až v bootstrapu to nejde:(

<?php
	$Container->addService('Db', function($Container) {
    		return new Nette\Database\Connection(
        		$Container->parameters['dsn'],
        		$Container->parameters['user'],
        		$Container->parameters['password']
    		);
	});
	$Db = $Container->Db;
	$Db->... //Netbeans nenapovídá
?>

Nicméně já v configu Db definuji a z ní pak přečtu přístupy do další DB a vytvářim service s novými přístupy + starou service odstraňuji. Myslíš, že by šlo místo toho harakiri pouze v určité chvíli zkrátka u té service jen změnit přístupové údaje a tím z jednoho připojení udělat jiné, aniž bych staré mazal a nové vytvářel? To by mohlo být finální řešení.

Editoval Swed (14. 5. 2012 0:58)

V presenteru musíš přes kontext. ;-)

$this->getContext()->db->... //tady už by nápověda měla fungovat

Změnit přístupové údaje by možná šlo – Nette\Database spojení myslím vytváří až když je třeba, takže by to mohlo jít.

Nebylo by ale možné mít pro každou aplikaci zvláštní config a v bootstrapu loadovat nejdříve ten společný a potom na základě podmínek nějaký další? Tohle jsem nikdy nepotřeboval ani nezkoušel takže jen hádám, nevím jestli je to možné.

EDIT: Jo aha, ty ty přístupy získáš až dynamicky, tím to samozřejmě padá (leda bys dynamicky vytvářel config).

EDIT2: Nejspíš bys ale mohl v configu vytvořit nějakou dummy service (klidně se špatnými přístupy), v bootstrapu ji odstranit ($container->removeService(‚…‘)) a poté přidat tu správnou. Tuhle dummy service by navíc stačilo vytvářet jen v development režimu.

Editoval jtousek (13. 5. 2012 15:06)

Chápu. Ono to vytváření service dynamicky v bootrapu není problém, jen pak chybí to napovídání jestli tě dobře chápu. V tom případě by v tom development režimu opravdu mělo stačit přidat do configu connection s nefunkčními přístupy a pak ji v bootstrapu nahradit tou správnou. IDE nic nepozná.

Tak jsem to předělal a používám tedy service. V bootstrapu ji přepíšu a našeptávání už funguje dobře!

Nicméně v debugbaru stále SQL nemám:( Takže jediná změna oproti mému původnímu řešení je, že když volám constructor modelu v presenteru, musím mu předávat připojení k DB:-D. Takže se vracím k původní otázce: Nenapadá někoho jak SQL v debugbaru zapnout?:)

Tohle jsem vyčetl z NetteExtension.php:

			if (!$container->parameters['productionMode'] && $info['debugger']) {
				$panel = $container->addDefinition($this->prefix("database.{$name}ConnectionPanel"))
					->setClass('NDatabasePanel')
					->setAutowired(FALSE)
					->addSetup('$explain', !empty($info['explain']))
					->addSetup('NDebugger::$bar->addPanel(?)', array('@self'));

				$connection->addSetup('$service->onQuery[] = ?', array(array($panel, 'logQuery')));
			}

Třeba tě to nějak inspiruje.

Funkce createServiceNette__database__default() a createServiceNette__database__defaultConnectionPanel() jsem včera také objevil, ale nepodařilo se mi bohužel pomocí nich nic změnit. Každopádně Vám oběma děkuji.

Zato jsem zkusil ještě jednu věc, která problém vyřešila. Zkončila ale zajímavou chybou, která mi vrtala hlavou až do půl 3 do rána a vlastně vrtá do teď:) Zkusil jsem se připojit k DB hned za zavoláním konstruktoru Configuratoru a ještě před načtením neonu. Zjistil jsem přístupy do DB a ty jsem pak předal Configuratoru pomocí

<?php
	$Configurator->addParameters($params);
?>

a použil v configu:) Našeptávání funguje, v debugbaru se objevily dotazy, ale aplikace přestala fungovat a začala hlásit chyby při zpracování výsledků dotazů.

Při bližším zkoumání jsem zjistil, že DB funguje správně, ale přestal fungovat přístup, jakým jsem přistupoval k výsledkům dotazů. Je možné, že jsem to předtím používal špatně a teď správně, ale proč to předtím jelo a teď ne? To je mi záhadou. Navíc teď nevím, jak udělat rekurzivní výpis stromu, který jsem měl tak dobře udělaný:(

Zkrátka původně jsem se v jednotlivých řádcích výsledku dotazu mohl pohybovat přes indexy např takto:

<?php
	$Tab = $this->Database->table('menu')->where('active', 1);
	$Tab[0] //object reprezentující 1. řádek
?>

No a to teď nefunguje. Ani když použiju (array) $Tab, tak nedostanu stejný výstup jako před změnami. Vadí mi to víceméně jen u těch rekurzivních algoritmů, ale je to pro mě záhada. Jak je možné, že jednou jde s výsledkem dotazu nějaké třídy pracovat nějak a jindy při použití stejné třídy už ne?

Editoval Swed (14. 5. 2012 22:38)

To je zvláštní, ten ArrayAccess by měl normálně fungovat. Nevidím žádný důvod proč by v určitém případě fungovat neměl. Neměnils něco v těch dotazech, že pak třeba nevracely žádné výsledky nebo tak něco?

Pokud jde o rekurzi tak v šablonách se používá rekurzivní volání bloků. Mimo šablony pokud to potřebuješ jen projít a zpracovat mi stejně připadá lepší než index do pole používat iterátor – což ti více méně dělá ten fetch.

No hlavně že už to funguje. :-) Tu databázi používáš poměrně specifickým / málo obvyklým způsobem se kterým se zrovna nepočítalo. Samozřejmě, že v tomhle případě bych to asi neřešil jinak, respektive jediná alternativa je jeden centrální uživatel s přístupem ke všem databázím. Předpokládám ale že jsou / časem mohou být rozeseté po různých serverech a v takovém případě by to stejně nešlo.