tiny ‘n’ smart
database layer

Odkazy: dibi | API reference

Oznámení

Omlouváme se, provoz fóra byl ukončen

Object of class DibiRow could not be converted to string

před 10 lety

BigCharlie
Člen | 267

V některých případech jsem narazil na excelentní chybovou hlášku, uvedenou v předmětu. Postupným píděním jsem došel k tomu, že od zhruba PHP verze 5.2 (možná nějaké drobné k tomu) není podporována implicitní konverze objektů na string.

Já jsem narazil na chybu při přiřazení dat z tabulky do proměnné, kde se mezi data tabulky míchaly znaky. V dotazu jsem načítal formátované datum. Zhruba takto:

SELECT DATE_FORMAT(datum, ‚%d. %c.‘) AS datum …

Podivné je, že jsem tuto chybu schopen replikovat ve 100%, ovšem identický kód, pracující se stejným dotazem, daty i okolnostmi, ovšem umístěný v jiném skriptu, pracuje bezchybně.

Řešením v mém případě je přidat objektu DibiRow metodu __toString:

public function __toString() {
    $iterator = $this->getIterator();
    return $iterator->current();
}

Asi by stálo za úvahu upravit to v další revizi!

Editoval BigCharlie (5. 3. 2009 13:25)

před 10 lety

David Grudl
Nette Core | 6806

Nevidím v tom chybu dibi. Můžeš poslat celý snippet, který způsobuje problém?

před 10 lety

BigCharlie
Člen | 267

Jde o kód, který připravuje data pro PDF.

Takto se získávají data toho případu, který mi vracel chybu:

$res = dibi::query("SELECT DATE_FORMAT(datum, '%d. %c.') AS datum FROM prihlaska_obed
JOIN obed USING (obed_id) WHERE prihlaska_id = $prihlaska_id ORDER BY obed_datum");
if ($res->count()) {
    $this->application_data['obedy'] = $res->fetchAll();
}

A tady, na označeném řádku došlo při třetím průchodu k chybě:

foreach ($this->application_data['obedy'] as $v) {
    $obed_no = isset($obed_no) ? $obed_no . "\n" . $v:$v;
}

Jak jsem psal prve, je to zvláštní. Zkoušel jsem i změnit dotaz (tak, že vracel jen textovou konstantu). Chování stejné. Pokud nechám vypsat proměnnou $this->application_data[‚obedy‘], což bylo pole se třemi hodnotami, všechny tři jsou stejné. Vardump:

array(3) {
    [0]=>  object(DibiRow)#96 (1) {
        ["datum"]=>  string(6) "27. 5."
    }
    [1]=>  object(DibiRow)#97 (1) {
        ["datum"]=>  string(6) "28. 5."
    }
    [2]=>  object(DibiRow)#98 (1) {
        ["datum"]=>  string(6) "29. 5."
    }
}

Možná ještě kde jsem se pídil a dopídil možného vodítka:

Původně jsem se nekoukal na php.net, tak jsem to napravil:

před 10 lety

LM
Člen | 206

Já to teda nějak pozorněji nezkoumal, ale nemělo by v tom cyklu být spíš:

$obed_no = isset($obed_no) ? $obed_no . "\n" . $v->datum : $v->datum;

před 10 lety

David Grudl
Nette Core | 6806

Jak píše LM, je potřeba vypisovat vždy konkrétní prvek. Nebo místo $res->fetchAll(); použít $res->fetchPairs();

před 10 lety

BigCharlie
Člen | 267

LM napsal(a):

Já to teda nějak pozorněji nezkoumal, ale nemělo by v tom cyklu být spíš:

$obed_no = isset($obed_no) ? $obed_no . "\n" . $v->datum : $v->datum;

Byl jsem si celkem jistý, že jsem to zkoušel, ale pro jistotu jsem si to teď opět ověřil. Výsledkem je „Notice: Trying to get property of non-object“. Takže tudy cesta zcela jistě nevede.

A vzhledem k tomu, že je to pole řetězců, tak na konstrukci „foreach as“ nevidím nic špatného ani zavádějícího?

před 10 lety

David Grudl
Nette Core | 6806

Ale to není pole řetězců, nýbrž objektů DibiRow.

před 10 lety

BigCharlie
Člen | 267

David Grudl napsal(a):

Ale to není pole řetězců, nýbrž objektů DibiRow.

Hlavně že jsem si to pečlivě ve vardumpu vypsal a všude object dibiRow svítí. Postavím se před nastoupenou jednotku a zastřelím se pro výstrahu, pomoci mi netřeba.

Ale nedalo mi to a zkusil jsem znovu variantu

$obed_no = isset($obed_no) ? $obed_no . "\n" . $v->datum : $v->datum;

Našel jsem sám sobě chybu v přepisu, tím jsem se zbavil hlášky o neexistující vlastnosti objektu. Ovšem výsledek je stále stejný – „Object of class DibiRow could not be converted to string“.

Tak jsem zkusil variantu s fetchPairs. Výsledek mě překvapil – skutečně jsem neočekával, že přestanu mít problémy s tímto úsekem kódu a začně zlobit kód, mající na starosti de facto totéž, ovšem vypisující data z jiné tabulky v databázi. Podotýkám, že s ním předtím problémy nebyly, testuji na totožných datech. Když jsem i ten přepsal na fetchPairs, funguje vše bez problémů.

Díky za rady.

Záhadou pro mě zůstává proč v případě že použiju fetchAll a $v->datum, narazím na původně hlášenou chybu?