inicializace DIBI connection z NETTE

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
symmetry
Člen | 71
+
0
-

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
+
0
-

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
+
0
-

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
+
0
-

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
+
0
-

_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
+
0
-

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
+
0
-

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ř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;
    }
}

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
+
0
-

_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
+
0
-

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ř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;
    }
}

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.

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
+
0
-

_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
+
0
-

Jéje, to jsem to pěkně popletl.

  1. Ne Laděnka, ale ErrorPresenter nebude mít šanci – uživatel uvidí bílou stránku.
  2. „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
+
0
-

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 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.

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.