ugrás a tartalomhoz

dbobj: magyar fejlesztésű objektum perzisztencia modul PHP-hez

thefirstofall · 2006. Dec. 19. (K), 09.13
PHP kiegészítő Bankó Ádám fejlesztésében
 ■
1

Weboldal

thefirstofall · 2006. Dec. 19. (K), 09.37
A véleményeteket / tanácsotokat kérem, hogyan tehetném a projekt oldalát barátságosabbá?
4

Néhány szín, kép?

krey · 2006. Dec. 19. (K), 20.55
Mondjuk eggyel kevesebb gépelési hibával a címben ;)
dbobj - an open source object persistence layer for PHP

Ha kell setígség, szívesen átrajzolom egy kicsit, bár w3m-ben így is tökéletes.

üdv. krey

ps. egy nagy, fényes, wet floor-os Download now gomb :)
pps. Amúgy remek dolognak tartom (amennyire 10 perc alatt át lehetett nézni a példa source-t), de nem nagyon PHP-s ;)
5

nem nagyon PHP-s?

thefirstofall · 2006. Dec. 19. (K), 22.51
Először is köszi, hogy felhívtad a hibára a figyelmemet, már javítottam.

Másodszor mit értesz azon, hogy nem nagyon PHP-s a példa source?
6

ja igen

krey · 2006. Dec. 20. (Sze), 00.21
Csak a felfogás miatt, ahogy te is írtad:
A dbobj pedig elvégzi az adatbázis kezelését helyetted.

Ettől nem lesz PHP-s :)
Attól, hogy objektumokat kezelsz és a háttérben adatbázisműveletek játszódnak le.
A kód maga attól, hogyha nem lennének benne . , -> és hasonló jelek, akkor nem tudnám, hogy milyen nyelven van, ez nem feltétlenül rossz :D
Mellesleg egy windows build nem lenne rossz, egy MySQL (InnoDB) verzióról nem is beszélve.

üdv. krey

ps. a dbobj név jellemző... Miért nem lehet valami hangzatos nevet adni az ilyen jó kis projecteknek? A Firefoxot sem hívják opensourceXULandJSbrowser-nek (OSXULAJSB)
9

Ez van...

thefirstofall · 2006. Dec. 21. (Cs), 00.50
MySQL támogatás előbb-utóbb lesz (ahogy van időm az egyetem mellett)
Windows-on viszont már most lefordul és működik a dolog.

A név választással kapcsolatban pedig ... nyitott vagyok a javaslatokra :) Tekintsük a dbobj-ot fejlesztési kódnévnek.
2

miert?

deejayy · 2006. Dec. 19. (K), 13.26
ommm, ez most miert is jo?
3

azért, mert ...

thefirstofall · 2006. Dec. 19. (K), 19.46
Azért jó, mert SQL lekérdezések és parancsok írása helyett a program logikájának megvalósítására tudsz koncentrálni. A dolog egy teljesen objektum orientált felületet biztosít az adataid kezeléséhez. A dolog akkor érdekes, ha amúgy is objektum-orientáltan készíted a PHP programot, mert így nem kell azzal foglalkoznod, hogy az adatok hol és hogy vannak tárolva. Egyszerűen meghatározod az osztályaidat és használod az objektumaidat. A dbobj pedig elvégzi az adatbázis kezelését helyetted.
7

Active Record

Sulik Szabolcs · 2006. Dec. 20. (Sze), 20.52
Hallottál már az Active Record (AR) nevű találmányról. Első blikkre amit készítettél az pontosan az. Illetve nem pontosan az, hiszen AR-nál nincs szükség az osztály elején a mezők leírására, ugyanis azt az információt közvetlenül az adatbázisból nyeri (magyarul elég egy táblanevet megadni neki).

Viszont kiváncsi lennék, hogy ez mennyivel jobb, mintha pl. az AdoDB ActiveRecord osztályát használnád?

Egyébként az AR egy nagyon szép implementációját láthatod müködés közben, ha kipróbálod a CakePHP-t (Rails-szerű framework php alapon).
8

Pontosan!

thefirstofall · 2006. Dec. 21. (Cs), 00.44
Nagyon köszönöm a kérdést.

Had idézzek a az általad linkelt hanlapról:
Another issue is performance. For performance sensitive code, using direct SQL will always be faster than using Active Records due to overhead and the fact that all fields in a row are retrieved (rather than only the subset you need) whenever an Active Record is loaded.


A dbobj projekt célja pontosan az, hogy egy olyan ORM rendszert hozzunk létre, aminek teljesítménye - sok esetben - megközelíti a közvetlen SQL -alapú adatbázis kezelés teljesítményét.
Ezért van az, hogy ő nem térképezi fel minden futásnál az adatbázist, mivel ez sok felesleges műveletet eredményez. Szintén ezért készült a modul C-ben, és nem PHP-ban.

Ez természetesen azt jelenti, hogy felhasználási köre jóval szűkebb, mint a "programozóbarátabb" társaié, viszont a teljesítménye miatt alkalmas erőforrás-kritikus siteok és alkalmazások meghajtására is.

Ha egyszer lessz időm, akkor megírom a kompatibilitási réteget az ADOdb Active Record-hoz és a többi hasonló PHP-s megoldáshoz, hogy ha egy site kinövi erőforrásait, akkor minél egyszerűbben lehessen áttérni dbobj-ra.

Tudom, hogy a dbobj konfigurálása egy kicsit körülményes, de ez azért van, hogy - némi PHP kódolással - bármelyik ADOdb Active Record szerű megoldás helyére be lehessen állítani jelentős teljesítmény romlás nélkül.
10

Észrevétel

Sulik Szabolcs · 2006. Dec. 21. (Cs), 09.40
Most már tisztábban látom a dolgot. Ezek szerint a cél gyakorlatilag egy adodb készítése csak C extensionként.

Viszont azt vettem ki a példakódból, hogy a db kapcsolathoz be kell állítani a dbobj.connStr php változót. Azonban sok (leginkább ingyenes) tárhely tiltja az ini_set függvényt és társait (ahogy a .htaccess-t is), ezért itt teljesen használhatatlan (ingyenes szervereken).
Mi lenne, ha eleve a php-s $dbobj_config-ban szereplnének az adatbázis adatai.

Megnéztem a forum példakódot is. Ez a dbobj_find függvény használata kicsit macerásnak tűnik. Nem lenne egyszerűbb egy alábbi megvalósítás (?) :
class user extends dbobj {
...
}

$user->id = $id;
$user->current();
Ahol a $user->current() automatikusan futtatja a dbobj_find()-ot az adott objektumon az user->id mezőre, mint feltételre (az id helyett minden esetben persze a kulcs szerepel). (Tudom, kicsit /nem is kicsit/ cakephp-s, de hát annyira tetszik.)

Ui: látom én, hogy a dbobj_find() ennél szélesebb körű használatra hivatott (bármelyik mező alapján mehet a lekérdezés), viszont most az objektumot csak adattárolásra használod, a funkciók külső függvényekkel van megoldva.
11

static function find

thefirstofall · 2006. Dec. 22. (P), 01.06
Igazad van, az adatbázis kapcsolat paramétereinek helye tényleg az osztályban van, majd ha lesz időm (pár más dolog mellett pl. case-sensitivity) ezt is átrakom az osztály-konfigba.

Ami a te általad mutatott keresési folyamatot illeti, nekem nem tetszik. Nem azért, mert nem lehetne megcsinálni, hogy a dbobj támogassa. Sőt ... talán még nem is lenne bonyolult.
Inkább koncepcionális problémám van vele: a $user objektum mi? Előszőr ugye csak egy üres objektum, amiben beállítasz pár paramétert, majd aztán kötöd össze egy adatbázis rekorddal. Ahogy én látom a dolgokat, ez nem konzisztens.
A dbobj filozófiája az, hogy egy kezelt objektum mindig kötődjön adatbázis-rekordhoz. Persze amikor új objektumot készítesz, akkor először az még csak a memóriában van, de előbb-utóbb mentésre kerül az adatbázisba (ha útközben nem törlöd).
Tehát ami nem tetszik nekem, az az, hogy egy értékadásnak látszó dolog egyszerre jelentheti egy adatbázisban található mező frissítését, és egy keresési paraméter állítását is. Szerintem ez igazából két különböző osztály (egy rekord-kereső, és egy rekord-kezelő) összemosása.

Abban megintcsak igazat adok neked, hogy a dbobj_find használata macerás. Ha Ruby-ban lennénk, akkor biztos másként lenne, de a PHP nem olyan Rugalmas nyelv, hogy öröklődéskor automatikusan lehessen statikus metódusokat definiálni, úgyhogy ezt kénytelen vagyok a programozóra bízni.

Az én megoldásom:

class user extends dbobj {
  ...
  static function find($what = array()) {
    return dbobj_find('user',$what);
     //később majd inkább dbobj::find(...)
  }
  ...
}

$user = user::find($id);
Ehhez mit szólsz?
12

Boldog karácsonyt

Sulik Szabolcs · 2006. Dec. 24. (V), 10.10
Értelek. Szóval keresési funkciókat a dbobj_find végzi, míg az objektumok csak az átmeneti tárolást és visszaírást (kezelési funkciók).
Viszont abban a pillanatban, hogy van egy user::find($id) metódusod, már össze is mostad a kettőt.
Tehát ami nem tetszik nekem, az az, hogy egy értékadásnak látszó dolog egyszerre jelentheti egy adatbázisban található mező frissítését, és egy keresési paraméter állítását is.

Ez nagyon szépen különválasztható, hiszen a user::id = "valami" csak egy értékadás, a funkciót az utána hívott függvény látja el (legyen a neve akár user::current() vagy user::read() ami beolvas, esetleg user::set() vagy user::save() ami pedig ment).
Most hogy így leírtam a dolgokat én is érzek benne némi inkonzisztenciát.

UI.: van a cucchoz némi doksi is(?), mert én nem találtam az oldalon és anélkül elég nehéz próbálgatni a dolgokat.
13

Boldog karácsonyt mindenkinek!

thefirstofall · 2006. Dec. 25. (H), 18.48
Először vitatkoznék veled:
A dbobj::find metódus statikus, nem (közvetlenül) az objektumokra vonatkozik, hanem az osztályra. Kicsit olyan, mintha lenne egy tábla (vagy osztály) osztály ( bár ez elég hülyén hangzik). Mindenesetre az objektumokon (azaz rekordokon) dolgozó (nem statikus) metódusok és osztályra (táblára) vonatkozó (statikus) metódusok szerintem jól elválnak egymástól. Gyakorlatilag a tábla-osztály, rekord-objektum analógiát használom. Lehet, hogy kicsit tényleg keverednek itt a dolgok, de szerintem még mindig jobban járunk ezzel, mintha lenne egy "osztály osztály". Ez így sokkal jobban integrálódik a PHP objektum orientált felületébe.

Ami a dokumentációt illeti: a cucchoz van egy elég komoly, sok oldalas (és magyar nyelvű) dokumentáció, amit a szakdolgozathoz csináltam. Ha lesz egy kis időm, kicsit megszerkesztem és egy wiki-n közzéteszem. Ha nem akarod megvárni, akkor küldj egy levelet, és elküldöm neked, csak nem akarom még ilyen nyers formában közzétenni.