Důležitá změna: vrátí fetch() objekt nebo pole?

Chování asociativního pole, tedy páry ‚klíč‘ ⇒ ‚hodnota‘, je zachováno, ať už je záznam reprezentován polem nebo objektem. Rozdíl je pouze v syntaxi, někdo preferuje $row['id'], jiný $row->id

Jaky na to to mate kdo nazor?? Ja za sebe musim rict, ze mi tako zmena pusobi v aplikaci pomerne zasadni problemy a konstatuji, ze mi tato zmena prijde jako chybny (lec v kontextu objektu nevyhnutelny) krok…:-(

Z ruznych duvodu (dibi je proste cool a ulehcuje mi nasledne praci) jsem implementoval dibi do frameworku, ktery momentalne pouzivam (je to custom zalezitost, takze nic znameho). V celem frameworku se s daty z databaze pocitalo jako s asociativnimi poli, takze stacilo prepsat tridy, ktere pracuji s databazi (at uz vkladani nebo vybirani dat). Bylo to docela v pohode, protoze z dibi lezlo presne to, co jsem potreboval.

Ted jsem chtel zacit pouzivat novou verzi dibi jednak kvuli opravam chyb a jednak jsem chtel zacit pouzivat DibiDatabaseInfo apod. Rikal jsem si, ze to nejak obejdu…jenze ve vsech tridach, ktere jakymkoliv zpusobem zpracovavaji data z databaze (DataGrid a jim podobne…) se ocekava $row jako asociativni pole a na spouste mistech jsou testy if(is_array($row)) apod. Takze se to cele sesypalo…premyslel jsem, ze bych i za cenu ztraty vykonu dopsal do obalove tridy pretypovani vsech polozek na array (jo je to brutalni, ale jak z toho jinak?)…u metody fetchAll to jde, ale u metody fetchAssoc je to dost problem…takze jsem se zase vratil zpet k predchozi verzi dibi a pochybuju, ze budu moct upgradovat, leda ze to fakt cele prepisu, do cehos se mi jednak nechce (a komu jo…) a jednak na to nemam cas…

U noveho projektu toto neni problem, protoze se s tim da pocitat. U rozjetych projektu uz to trochu problem je. A obecne…uz neni mozne jednoduse zmenit databazovy layer (at uz na dibi nebo zpet na cokoliv jineho), protoze tridy pro praci s daty musi nativne pocitat s dibi specifickou tridou DibiRow…cimz se aplikace stava na dibi zavisla (jedine, ze by obalova trida data nejak chroustala → ztrata vykonu a je to prasarna (podle me)). A me pripada, ze toto jde proci myslence dibi (jak jsem jiz naznacil nekde v prispevku vyse.

(to jsem se nejak rozepsal…snad je tomu rozumnet)

Takze jeden select je ve vysledku prohnam 3× nejakym cyklem.

Takze vlastne delas to, o cem jsem premyslel taky. Prevadis si vysledky tak, jak Ti vyhovuje…me to prijde silene neefektivni (btw. vysledky z fetchAssoc prevadis nejak rekurzivne?) === aplikace je zavisla na dibi a kdyz zmenis DB layer, tak musis prizpusobit i zpracovavani dat (a opacne).

Davide mozna by stalo za to nekde nejakym prepinacem zapinat stare chovani (misto objekut pole) ne?

A to uz jsme zase u toho, ze je nekde nejaky prepinac, na ktery se musi brat ohled vsude a musi se tedy nejak delegovat vsem castem dibi, ktere s daty pracuji. Tomu se David pocitam chtel touto upravou vyhnout. Proto mi prislo elegantnejsi, kdyz proste dibi vracelo pole a hotovo (ekvivalentni tomu, kdyby dibi vracelo objekty a tohotovo).

Resenim by mozna bylo vracet jen nejaky objekt, ze ktereho by se zavolanim nejake metody (napr. getAsArray) vracelo asociativni pole. To by mozna mohlo problem vyresit.

Editoval arron (21. 11. 2008 14:47)

Nechtěl jsem touto změnou způsobit někomu problémy, vlastně jsem čekal, že ten dopad bude mnohem menší. Když teď sleduju diskuse na PHP internals (array_key_exists BC break), tak vidím, jak rozpačité je chápání ArrayObject u samotných vývojářů jádra.

Ale s odstupem času to vnímám, jak píše arron, jako nevyhnutelný krok. Navíc se v tom skrývá budoucí potenciál, objekt DibiRow je možno naučit nějaké konverzní dovednosti.

arron napsal(a):

Takze vlastne delas to, o cem jsem premyslel taky. Prevadis si vysledky tak, jak Ti vyhovuje…me to prijde silene neefektivni (btw. vysledky z fetchAssoc prevadis nejak rekurzivne?)

Použij rovnítko:

$res = dibi::query('SELECT * ...');
$assoc = $res->fetchAssoc('='); // nebo třeba 'name,=,title,=' apod.
// -> returns arrays

arron napsal(a):

aplikace je zavisla na dibi a kdyz zmenis DB layer, tak musis prizpusobit i zpracovavani dat (a opacne).

Jak se to vezme, řádky jsou objektem ArrayObject, ten je na dibi nezávislý. Jako jediný objekt umí trik s přetypováním na pole (array) $row, do budoucna se dá předpokládat podpora v (dalších) nativních funkcích PHP.

A mozna uz je cas na nejaky priklad:-) (trochu to vytrhnu z kontextu, takze se neptejte proc a verte, ze to opravdu pouzivam a moc jinak no nejde ;-))

Mejme dve tabulky. V jedne je vybaveni (cekoholiv, treba aut) a ve druhe ruzne kategorie, do kterych se vybaveni prirazuje.

Vybirani dat muze vypadat treba takto:

$res = dibi::query("SELECT * FROM equipment JOIN equipment_cateogries USING(equipment_category_id)");

//priprava dat na dalsi zpracovani
$data = $res->fetchAssoc("equipment_category_name,equipment_id,#");

//plocha data
$data_flat = $res->fetchAll();

V prvnim pripade dostavam jako vystup neco takovehleho:

Array
(
  [BEZPEČNOST] => Array
    (
        [6] => DibiRow

        [7] => DibiRow
    )
)

Ve druhem pripade dostanu toto:

Array
(
  [0] => DibiRow

  [1] => DibiRow
)

ve chvili, kdy se budu snazit napsat univerzalni funkci pro prevod tohoto na pole poli, tak se budu muset poustet do neprijemnych rekurzi. Hezci by bylo:

$dataAsArray = $data->getAsArray(); //$data je nejaky objekt, ktery ma "vice tvari" (pole objektu a co ja vim co jeste)

$data_flatArray = $data_flat->getAsArray();

foreach($data_flatArray as $row)
{
  if(is_array($row)) //funguje;-)
  ...
}
//a obdobne pro $dataAsArray

arron napsal(a):

$data = $res->fetchAssoc("equipment_category_name,equipment_id,#");

Zkus $data = $res->fetchAssoc("equipment_category_name,equipment_id,#,=");. Funguje?

phx napsal(a):

Dale me napada, ze Dibi lze urcit jaky objekt ma vracet. Tz misto DibiRow si tam dej co potebujes a co bdue umet ono getAsArray(). (Osobne bych asi volil nazev toArray())

DibiRow (jakožto potomek ArrayObject) umí:

$arr = (array) $row;
// nebo
$arr = $row->getArrayCopy()

Uvnitř asociativní masky je možné určovat, jestli segment má být pole = nebo objekt @. Pokud není poslední segment specifikován (tj. není uvedeno ani = ani @), použije se výchozí @.

Jinak pomocí extension method lze přidat třídě DibiResult metody např. fetchArray & fetchAllArray, která bude vracet prvky jako pole.

funkce DibiResult::setObjects() byla přejmenována na setRowClass()