inicializace DIBI connection z NETTE
- symmetry
- Člen | 71
Zdravím, když jsem používal smaotné dibi nalinkoval jsem jenom cestu k dibi.php a uvedl
<?php
dibi::connect(array(
'driver' => 'mysql',
'host' => SQL_HOST,
'username' => SQL_USERNAME,
'password' => SQL_PASSWORD,
'database' => SQL_DBNAME,
'charset' => 'utf8',
));
?>
Nyní ale v NETTE stojím před otázkou zda musím toto provadět znovu,
tj. linkovat soubor k dibi.php k souboru db_connect.php , který pak includuji
do každého souboru.
Nebo jestli mohu využít nějakou metodu pro zavolání connectu na DB, kterou
bych pak includoval do každé stránky.
Díky za jakoukolliv radu.
- hurvajs
- Člen | 86
Nemusis, staci si do bootstrapu dat nacteni konfigurace a pak vyvtorit dibi connection.
<?php
// load configuration
Environment::loadConfig(CONF_DIR . '/global.ini');
// create a database connection via dibi
dibi::connect(Environment::getConfig('database'));
?>
Obsah konfig. souboru:
;; database connection
database.driver = mysqli
database.charset = utf8
database.host = xxx
database.database = xxx
database.username = xxx
database.password = xxx
database.lazy = true
A osobne v modelech pristupiji k dibi staticky a pres fluent:
<?php
dibi::getConnection()
->select()
...
->execute();
?>
- Ondřej Mirtes
- Člen | 1536
Já preferuji cestu BaseModelu, od kterého dědí všechny ostatní modely.
DibiConnection je pak přístupná přes $this->db
, třída
je snadno rozšiřitelná a v případě přechodu na jiný databázový layer
lze díky BaseModelu zajistit i zpětnou kompatibilitu.
Taky mi to ulehčilo hodně práce, když jsem přecházel na PHP 5.3 a
namespaces, nemusel jsem v každém modelu připisovat \
před
dibi
.
Asi nejjednodušší implementace:
abstract class BaseModel extends Object {
private static $db;
public function getDb() {
if (self::$db == NULL) {
self::$db = new DibiConnection(Environment::getConfig('database'));
}
return self::$db;
}
}
Editoval LastHunter (6. 11. 2009 17:03)
- _Martin_
- Generous Backer | 679
hurvajs napsal(a):
Nemusis, staci si do bootstrapu dat nacteni konfigurace a pak vyvtorit dibi connection.
<?php // load configuration Environment::loadConfig(CONF_DIR . '/global.ini'); // create a database connection via dibi dibi::connect(Environment::getConfig('database')); ?>
Dobrá myšlenka, nešťastná implementace. V případě vyhození výjimky z dibi (třeba když selže připojení) nemá šanci ani Laděnka. Řešením je:
// v bootstrapu
$application->onStartup[] = 'Database::initialize';
a
// třeba v souboru database.php ve složce modelů
class Database extends Object
{
public static function initialize()
{
dibi::connect(Environment::getConfig('database'));
}
}
- Ondřej Mirtes
- Člen | 1536
_Martin_: Takhle jsem to jeden čas měl, ale přestane to být použitelné ve chvíli, kdy se už u definice rout potřebuješ připojit k DB.
- hurvajs
- Člen | 86
LastHunter napsal(a):
_Martin_: Takhle jsem to jeden čas měl, ale přestane to být použitelné ve chvíli, kdy se už u definice rout potřebuješ připojit k DB.
Presne tak, z drtive vetsiny potrebuji nakopnout DB okamzite po nacteni konfiguraku a nastaveni nejzakladnejsich parametru enviromentu.
- hurvajs
- Člen | 86
LastHunter napsal(a):
Já preferuji cestu BaseModelu, od kterého dědí všechny ostatní modely.
DibiConnection je pak přístupná přes
$this->db
, třída je snadno rozšiřitelná a v případě přechodu na jiný databázový layer lze díky BaseModelu zajistit i zpětnou kompatibilitu.Taky mi to ulehčilo hodně práce, když jsem přecházel na PHP 5.3 a namespaces, nemusel jsem v každém modelu připisovat
\
předdibi
.Asi nejjednodušší implementace:
abstract class BaseModel extends Object { private static $db; public function getDb() { if (self::$db == NULL) { self::$db = new DibiConnection(Environment::getConfig('database')); } return self::$db; } }
I ja vyuzivam BaseModel
, ale osobne razim nazor, ze neni treba
ukladad dalsi promenou (at uz v modelu nebo kdekoliv jinde), kdy ji mam
pristupnou staticky odkudkoliv. Podle me je lepsi proste k dibi pristoupit
pomoci dibi::getConnection()
. A mam dokonce takove tuseni, ze to
tak i p. Grudl zamyslel a ze je prave proto dibi
staticky objekt.
Ulozeni do BaseModelu
je myslenka dobra, me se moc nezamlouva. Take
nehlede na to, ze nevidim moc rozumny duvod proc prechazet na jiny DB layer. To
bych musel pak prepsat vsechny modely, tedy pokud bych nechtel pouzivat ten novy
jen nekde. To uz radeji prejdu na ZF, ktere se mi zacina libit vice a vice (a ma
i hodne prednosti pred Nette – bez urazky Davide).
Nicmene, co se tyce PHP 5.3 to jsem jeste nezkousel, protoze nemam hosting (ani nevim o zadnem), kde by jelo uz JEN PHP 5.3.
- hurvajs
- Člen | 86
_Martin_ napsal(a):
Dobrá myšlenka, nešťastná implementace. V případě vyhození výjimky z dibi (třeba když selže připojení) nemá šanci ani Laděnka.
Jses si tim 100% jisty? V tom pripade jsem pokoril p. Grudla, Ladenku a hacknul cely internet… :-D Stacilo k tomu stopnout MySQL a moje super hacknuta Ladenka vypsala tohle:
DibiDriverException #2002
Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
Oslavujme…
- Ondřej Mirtes
- Člen | 1536
hurvajs napsal(a):
LastHunter napsal(a):
Já preferuji cestu BaseModelu, od kterého dědí všechny ostatní modely.
DibiConnection je pak přístupná přes
$this->db
, třída je snadno rozšiřitelná a v případě přechodu na jiný databázový layer lze díky BaseModelu zajistit i zpětnou kompatibilitu.Taky mi to ulehčilo hodně práce, když jsem přecházel na PHP 5.3 a namespaces, nemusel jsem v každém modelu připisovat
\
předdibi
.Asi nejjednodušší implementace:
abstract class BaseModel extends Object { private static $db; public function getDb() { if (self::$db == NULL) { self::$db = new DibiConnection(Environment::getConfig('database')); } return self::$db; } }
I ja vyuzivam
BaseModel
, ale osobne razim nazor, ze neni treba ukladad dalsi promenou (at uz v modelu nebo kdekoliv jinde), kdy ji mam pristupnou staticky odkudkoliv. Podle me je lepsi proste k dibi pristoupit pomocidibi::getConnection()
. A mam dokonce takove tuseni, ze to tak i p. Grudl zamyslel a ze je prave protodibi
staticky objekt. Ulozeni doBaseModelu
je myslenka dobra, me se moc nezamlouva. Take nehlede na to, ze nevidim moc rozumny duvod proc prechazet na jiny DB layer. To bych musel pak prepsat vsechny modely, tedy pokud bych nechtel pouzivat ten novy jen nekde. To uz radeji prejdu na ZF, ktere se mi zacina libit vice a vice (a ma i hodne prednosti pred Nette – bez urazky Davide).Nicmene, co se tyce PHP 5.3 to jsem jeste nezkousel, protoze nemam hosting (ani nevim o zadnem), kde by jelo uz JEN PHP 5.3.
Ta sance, ze budes potrebovat jiny DB layer, tu vzdycky je a nikdy nerikej
nikdy. Je dobre byt pripraven na vse. Pouzitim statickych metod tridy
dibi
(napr. dibi::fetchAll
) se odriznes od moznosti
v budoucnu neco menit. Naopak, pokud bys mel $this->db
, tak je
cely BaseModel takovy „blackbox“ a klidne mu muzes zmenit cele vnitrnosti,
pricemz zachovas syntaxi z dibi.
A jak rikas, pouzivat dibi::getConnection()
a na tom az metody
dibi, tak ten kod provadi prakticky to same, co moje $this->db
,
akorat se vic upises a ochuzujes se o ty mozne budouci upravy.
Ale nerikam, ze pouzivani dibi::
je spatne, jen uz jsem nasel
jeho nevyhody.
- Honza Marek
- Člen | 1664
_Martin_ napsal(a):
hurvajs napsal(a):
Nemusis, staci si do bootstrapu dat nacteni konfigurace a pak vyvtorit dibi connection.
<?php // load configuration Environment::loadConfig(CONF_DIR . '/global.ini'); // create a database connection via dibi dibi::connect(Environment::getConfig('database')); ?>
Dobrá myšlenka, nešťastná implementace. V případě vyhození výjimky z dibi (třeba když selže připojení) nemá šanci ani Laděnka. Řešením je…
Což takhle vrznout mezi načtením konfigurace a připojením k databázi Debug::enable()? Nemluvě o možnosti mít lazy připojení, že se dibi připojí až při prvnim dotazu.
- _Martin_
- Generous Backer | 679
Jéje, to jsem to pěkně popletl.
- Ne Laděnka, ale
ErrorPresenter
nebude mít šanci – uživatel uvidí bílou stránku. - „Líné“ připojení, jak psal Honza, by mohlo řešit i routy – v případě vlastního routeru či filtrovacích funkcí. Samotné „provádění“ rout je až po „startu“ aplikace.
Snad už to píšu dobře=)
- hurvajs
- Člen | 86
LastHunter napsal(a):
Ta sance, ze budes potrebovat jiny DB layer, tu vzdycky je a nikdy nerikej nikdy. Je dobre byt pripraven na vse. Pouzitim statickych metod tridydibi
(napr.dibi::fetchAll
) se odriznes od moznosti v budoucnu neco menit. Naopak, pokud bys mel$this->db
, tak je cely BaseModel takovy „blackbox“ a klidne mu muzes zmenit cele vnitrnosti, pricemz zachovas syntaxi z dibi.A jak rikas, pouzivat
dibi::getConnection()
a na tom az metody dibi, tak ten kod provadi prakticky to same, co moje$this->db
, akorat se vic upises a ochuzujes se o ty mozne budouci upravy.
To samozrejme nerikam, vzdy tady ta moznost je. Ono by tak modely meli take
fungovat, jako blackbox. Jen jsem chtel rici, ze je to proste podle
dost zavadejici, pouzivat primo v abstraktni tride BaseModel
vlastnost $this->db
. Protoze se treba muze stat, ze vyber dat
nebude pomoci databaze, ale SOAP. BaseModel
by mel tedy jen
obsahovat opravdu obecne vlastnosti. A uznej sam, ze kdyz budu napr. vyuzivat
jiny model, tak ziskani dat pomoci
<?php
$data = $this->db->select()...;
?>
je v tomto pripade absolutne zavadejici. Prave z tohoto duvodu, resim
pristup k dibi
jen na urovni daneho modelu a jen statcky.
Ale nerikam, ze pouzivani
dibi::
je spatne, jen uz jsem nasel jeho nevyhody.
Jestli mohu prozradit na jakeze jsi narazil nevyhody. Ja s tim tedy problem nemam.