Oznámení
fetchAssoc a nerozpoznanie property
před 9 lety
- westrem
- Člen | 398
Zdravim,
dnes som narazil na jednu zvlastnost ked mi Dibi zacalo hadzat vynimku (API)
throw new InvalidArgumentException("Unknown column '$as' in associative descriptor.");
Dovodom bol fakt, ze som sa pokusil o nasledovne:
$r->fetchAssoc('id');
Kde vsak $row
mal danu property id
ako private a
pristupit sa k nej dalo pomocou getteru getId
pripadne vdaka
magickej metode __get
u DibiObject-u.
Tymto sposobom vsak fetchAssoc zlyha na kontrole ci existuje dana property,
pretoze property_exists
nedokaze skontrolovat existenciu property
pokial je pristupna aj inak ako len napriamo. Samotnemu vykonaniu kodu to vsak
nevadi, pretoze pri neskorsom volani napr. $row->$as
sa pristupi
vdaka __get
metode priamo k pozadovanej private property.
Navrhujem preto zmenit podmienku na riadku 315 z
if ($as !== '[]' && $as !== '=' && $as !== '->' && $as !== '|' && !property_exists($row, $as)) {
...
}
na
if ($as !== '[]' && $as !== '=' && $as !== '->' && $as !== '|' && !property_exists($row, $as) && !method_exists($row, 'get'.ucfirst($as))) {
...
}
To by kontrolovalo existenciu gettera na danu property a mohlo by sa to
vyuzit v nasledovnom kode.
Pripadne ak existuje efektivnejsie riesenie tohto „problemu“ tak sem s nim,
vyssie uvedena podmienka je len moj „hot fix“, ktory ako sami isto viete
spolieha v pripade neexistencie priamo dostupnej property na pretazovanie
pomocou __get
.
před 9 lety
- phx
- Člen | 652
Zdravim
Koukam, ze se to zatim nijak nepohnulo. Navrhovane reseni ale stejnak nespolupracuje s Ormionem kde je pretizena __get a spol.
Proto navrhuji toto:
if ($as !== '[]' && $as !== '=' && $as !== '->' && $as !== '|' && !(property_exists($row, $as) || (method_exists($row, '__isset') && isset($row->$as)))) {
// atd ...
}
Potom je na programatorovi zda v metode __isset() pozavuje NULL za hodnotu nebo ne (isset() vs key_exists() v poli).
Hude nejaky ofcialni FIX???