model

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

Čau Dave, jaký plánuješ další vývoj Modelu? Dibi je sice mocná knihovna, ale pro větší projekty by to chtělo nějaké zapouzdření… Alespoň nějaký základni ActiveRecord by se hodil…

David Grudl
Nette Core | 8082
+
0
-

Na limity dibi občas narážím, zejména při hodně dynamickém generování SQL dotazů. Takže je mi jasné, že to další vývoj potřebuje. Ale jestli ji rovnou zapouzdřit v Nette?

To je tak:

  1. céčkové API databází zapouzdřují PHP funkce
  2. PHP funkce zapouzdřuje IDibiDriver
  3. dibi drivery zapouzdřuje DibiConnection (a sekunduje mu DibiTranslator nebo registr Dibi)
  4. zkusil jsem experimentálně zapouzdřit i DibiConnection, a to do DibiTable nebo DibiDataSource

Čtvrtá vrsta je asi ta, kterou máš na mysli. Kvůli komunikaci mezi Nette a dibi vznikl interface IDataSource, jeho výchozí implementací je zmíněný DibiDataSource. Zatím jde o velmi hrubý nástřel, vývoj je otevřený. Každopádně mám představu, že na straně Nette budou existovat pouze rozhraní a implementace bude mimo (tedy v dibi, nebo v nějakých add-ons pro jiné DB, …).

phx
Člen | 651
+
0
-

Rad bych zde nastinil svoje veci co pouzivam. Treba se to nejak ujme;)

Vzhledem k tomu, ze pouzivam Eclipse PDT a mam rad kontextovou napovedu tak pouzivam toto. (btw v cem kdo programujete?)

  1. DBModel
    • atributy = moje php promena mapovana dle transformacniho pole do DB a zpet
    • static getTable() = nazev tabulky v DB
    • static getDBPK() = PK v DB (nepodporuji vice sloupcu jako PK:( )
    • static getPK() = PK v modelu
    • getFromDBAssocArray(array) = naplni model dle asoc array z DB
    • putToDBAssocArray() = opak getFromDBAssocArray()
    • getColumn(string) = vrati nazev DB sloupce dle nazvu v modelu
    • dale par metod na ladeni a gettry pro sablony…
    • vetsina je v univerzalnim predkovi, takze samotny DBModel konkretni tabulky ma jen atributy, transformacni pole a pak nezbytnych metod.
    • zvykl jsem si na to. Dotazy sice vypadaji kapku sloziteji diky volani getTable, getDBPK a getColumn, ale jsem kompletne odstinen od vzhledu DB (pojmenovani sloupecku). A navic mi editor napovida;) Coz me u DibiTable celkem mrzi. (ach ta lenost)
  2. DBReadService
    • dle nazvu modelu zvladne z DB vycucnout v podobe DBModelu getAll() a getByPK
    • takovy dobry start pro DB sluzby napr ciselniku
  3. DBWriteService (dedi od DBReadService)
    • pridava jeste insert, updateByPK, deleteByPK

Vse ma samozrejme vyjimky a dalsi veci okolo co se hodi. Je to takvy odrazovy mustek pro obsluhy DB.

Co myslite?

btw: co delam statne v Texy! ze u zanorenych seznamu nejsou puntiky?

veena
Člen | 98
+
0
-

David Grudl napsal(a):

Čtvrtá vrsta je asi ta, kterou máš na mysli. Kvůli komunikaci mezi Nette a dibi vznikl interface IDataSource, jeho výchozí implementací je zmíněný DibiDataSource. Zatím jde o velmi hrubý nástřel, vývoj je otevřený. Každopádně mám představu, že na straně Nette budou existovat pouze rozhraní a implementace bude mimo (tedy v dibi, nebo v nějakých add-ons pro jiné DB, …).

Kdyby se ti povedlo, že budou objekty aplikace nesvázané s ORM, tak to by bylo super. Tohle se žádnému php frameworku ještě nepodařilo.

Zřejmě mít doménové objekty zvlášť a ty by si volaly ORM pouze jako service persistentního úložiště v případě potřeby. Nicméně mě ani po několika nocích nenapadlo, jak by to použití mohlo vypadat, aby to programátora neobtěžovalo spoustou kódu a bylo také možné kdykoliv jednoduše switchnout ORM třeba na object-xml-mapper apod. Možná právě o to se snaží v php pomocí SDO http://cz2.php.net/…book.sdo.php

phx
Člen | 651
+
0
-

Co ja mam svuj DBModel (muzu ukazat:) tak je vazan na DB (xml a spol nepotrebuji a neresil jsem to), ale pak je neprakticke tvoreni dotazu na DB. Nebo nejak nemam predstavu jak dolovat data z nejakeho uloziste. SQL mi prijde asi nejshudnejsi. Nebo jakou mas predstavu?
U me dotaz vypada asi takto:

dibi::query("SELECT * FROM [".Model::getTable()."] WHERE [".Model::getColumn('jmeno')."] = %s", 'PHX');
veena
Člen | 98
+
0
-

Spíš bych si to představoval nějak tak, že v presenteru zavoláš metodu doménového objektu např:

$User->getUser('franta') nebo nějak jako $User->_manager->getUser('franta') nebo třeba $System->getUser('franta') to je asi v celku jedno.

A v té metodě se pak zavolá:
$storage->getUser($name)

kde $storage je objekt ORM, v jehož metodě pak může být něco jako:

$db->getUserByName($name)

Když vyměníš storage třeba za xml, tak si ho jen zinicializuješ jinym mapperem a v doménových objektech nic neměníš.

Ale je to prostě spousta psaní pro programátora navíc a samozřejmě by se mělo ošetřit to, aby se nedělaly zbytečné dotazy do databáze, pokud už data v doménovém objektu jsou. Možná to nějak honit přes settery a gettery…

Je tu nebezpečí, že takhle rozgranulované dotazy do databáze ji mohou přespříliš zatěžovat.

Přemýšlel sem, že pěkná optimalizace by byla, kdyby by se celá databáze uložila do paměti pomocí memcache. Při zápisu do databáze by pak měla běžet transakce ohraničující zápis do db tak aktualizování memcache. Samozřejmě nepoužitelné u statistických tabulek nebo databází s GB dat. Na nějaké stovky mega dat, by ale možná šlo.

paranoiq
Člen | 392
+
0
-

„Přemýšlel sem, že pěkná optimalizace by byla, kdyby by se celá databáze uložila do paměti pomocí memcache“

nesnažte se optimalizovat db stroj. jeho autoři to umí jistě lépe. pokud máte dobře nastavenou databázi a dost paměti, tak ty tabulky stejně v paměti jsou.

phx
Člen | 651
+
0
-

Take by se mi neco podobneho libilo. Ale chybi mi poradny napad. Zatim mi vyhovuje to co mam. Tz DBModely (s transformArray, ktere mi mapuje atribut modelu na sloupecek v tabulce) a k tomu DBService, ktera mi poskytuje getByXYZ, insert, updateByPK atd…

Ohlede prepnuti do XML by to bylo urcite zajimave, ale nevidim v tom zvlastni vyuziti pro bezici aplikace. Mozna pro vytvoreni nejakych malych app, kde nasazeni DB neni nutne/mozne.

Nedovedu si totiz predstavit jak by se nad XML delaly slozitejsi dotazy. getByPK insert updateByPK jsou jasny, ale neco s GROUP BY, MAX, atd by bylo vykonove asi v …, i kdyz otazka zni zda u malych projektu by neco takoveho bylo nutne.

Jeste drobnost. Nekde jsem kdysi potkal „DB v PHP“. Byly to serializovany pole s daty, ktere se insertly a jen se s nima nejak pracovalo pres klice v poli co foreach atd. Celkem pekne zneuziti PHP. Insert jen doplnil pole a ulozil zpet na disk.