---

$db = DB::connect("mysql://...", true);
[...]
var_dump($db->query("UPDATE ..."));

output:
int(1)

Alle andre queries jeg har prøvet med (bla. select og show) giver en fin
DB_Result tilbage.
Ifølge dokumentationen kommer der altid en DB_Result eller en DB_Error
tilbage. Hvorfor får jeg så bare en 1'er?

Opgradering fra en halvgammen pear til en næsten ny (hentet fra Debian
unstable i dag) ændrede intet...

Er der andre der har set det før?

Jeg tillader mig lige at spørge inden jeg har taget den komplette debug-tur
igennem (bla. fjerne alt der kan fjernes), da det haster. Men det vil jeg
gøre mens jeg venter på svar. :)

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

Niels Andersen wrote in <X57I9.60583$HU.4166399@news010.worldonline.dk>:
> Jeg tillader mig lige at spørge inden jeg har taget den komplette
> debug-tur igennem (bla. fjerne alt der kan fjernes), da det haster. Men
> det vil jeg gøre mens jeg venter på svar. :)

Jeg får stadig bare int(1). ARGH! :)

#!/usr/bin/php4 -qC
<?php
require_once('DB.php');
$db = DB::connect("mysql://***_dk:***@mysql.***.dk/**_dk");
var_dump($db->query("UPDATE temp SET word = word"));
?>

--
Mvh.

Niels Andersen

---

Niels Andersen wrote in <3c7I9.60612$HU.4166897@news010.worldonline.dk>:
> Jeg får stadig bare int(1). ARGH! :)
> var_dump($db->query("UPDATE temp SET word = word"));

Løsning:

$db->query("UPDATE ...");
$affectedrows = $db->affectedRows();

Det passer ikke lige med manualen, men det virker. Jeg laver nok en
bug-report senere.

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

On Fri, 06 Dec 2002 22:03:49 +0100, Niels Andersen wrote:

> Niels Andersen wrote in
> <3c7I9.60612$HU.4166897@news010.worldonline.dk>:
>> Jeg får stadig bare int(1). ARGH! :) var_dump($db->query("UPDATE
>> temp SET word = word"));
>
> Løsning:
>
> $db->query("UPDATE ...");
> $affectedrows = $db->affectedRows();
>
> Det passer ikke lige med manualen, men det virker. Jeg laver nok en
> bug-report senere.
Hej Niels,

Har lige læst beskrivelsen hos Pear og her fremgår det, at den som
input tager en variabel, men forholder det sig ikke sådan, at
DB::Connect i princippet returnerer en file descripter? Læser du om
xyx_connect på php.net, vil du også se, at disse funktioner
returnerer en ressource, som de forskellige andre DB-funktioner kan
anvende. Det er lidt ligesom i C/C++, hvor en file descripter også
er en integer, og de forskellige funktioner, der skal tilgå filen,
ved så hvordan en forbindelse åbnes, og ikke mindst hvordan
resultatet læses. Det din variabel udskriver er sådan set blot, at
du har fået tildelt en ressource med nummeret 1. En anden variant
kunne være, at den opfatter det boolsk, dvs. en ressource hvor
værdien er > 0 er true. Passer også ind i første variant, da den ved
ingen connection vil returnere false. PHP følger her C/C++
standarden, hvor alle værdier forskellig fra 0 (nul) er true, mens
værdien 0 (nul) er lig med false. Læg også mærke til at jeg ikke
skriver null, da det er noget helt andet, og også har forskellig
betydning i C/PHP og C++.

Håber mine små kommentarer giver dig et hint til løsningen.
--
Hilsen/Sincerely
Michael Rasmussen

"C makes it easy to shoot yourself in the foot; C++ makes it harder,
but when you do, it blows away your whole leg." - Bjarne Stroustrup
-------------------------------------------------------------------
Fjern NOSPAM fra min adresse, for at sende mig en mail

---

Michael Rasmussen wrote in <pan.2002.12.06.22.00.33.262876@datanom.net>:

> On Fri, 06 Dec 2002 22:03:49 +0100, Niels Andersen wrote:
>
>> Niels Andersen wrote in
>> Løsning:
>> $db->query("UPDATE ...");
>> $affectedrows = $db->affectedRows();

> Har lige læst beskrivelsen hos Pear og her fremgår det, at den som
> input tager en variabel,

Hvilken "den"?

> men forholder det sig ikke sådan, at
> DB::Connect i princippet returnerer en file descripter?

Nej, den returnerer et pear object, også ved fejl.

> Læser du om
> xyx_connect på php.net, vil du også se, at disse funktioner
> returnerer en ressource, som de forskellige andre DB-funktioner kan
> anvende.

Ja, men PEAR::DB er jo et abstraktionslag, så det kan du ikke bruge til
noget.

> Det er lidt ligesom i C/C++, hvor en file descripter også
> er en integer, og de forskellige funktioner, der skal tilgå filen,
> ved så hvordan en forbindelse åbnes, og ikke mindst hvordan
> resultatet læses.

I PHP er de forskellige pointere i dag en "ressource". Tidligere var det
bare en integer.
I PEAR::DB bliver der returneret objekter, som aflæses ved at bruge
objektets egne metoder.

> Det din variabel udskriver er sådan set blot, at
> du har fået tildelt en ressource med nummeret 1.

Nej, sådan er PHP ikke, ikke længere. Og PEAR::DB har vist aldrig fungeret
på den måde.

> Håber mine små kommentarer giver dig et hint til løsningen.

Sjovt svar at skrive til en løsning.

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

On Sat, 07 Dec 2002 14:56:44 +0100, Niels Andersen wrote:

> Michael Rasmussen wrote in
> <pan.2002.12.06.22.00.33.262876@datanom.net>:
>
>> On Fri, 06 Dec 2002 22:03:49 +0100, Niels Andersen wrote:
>>
>>> Niels Andersen wrote in
>>> Løsning:
>>> $db->query("UPDATE ...");
>>> $affectedrows = $db->affectedRows();
>
>> Har lige læst beskrivelsen hos Pear og her fremgår det, at den
>> som input tager en variabel,
>
> Hvilken "den"?
>
var_dump($db->query("UPDATE ..."));
Det var ovenstående, jeg referede til.

En kommentar til at PEAR::DB er et abstraktionslag. Det er vi helt
enige om, men fordi en klasse er et abstraktionslag, betyder det
ikke samtidig, at det ændrer på de underliggende funktioners
returtype. Var det tilfældet, ville jeg mene, at abstraktionslaget
var kodet forkert. En ting er at introducere nye funktioner/metoder,
med vær deres egne returtyper, men at ændre på de indbyggede
funktioners returtype, mener jeg, er farligt.

Så for at gøre en lang historie kort er jeg af den opfattelse, at
var_dump forventer en type som indput*), hvorimod PEAR::DB returnerer
objekter, og derfor vil var_dump udskrive ressourcens ID i stedet
for.

*) I PHP findes typen integer, real, string og array.
--
Hilsen/Sincerely
Michael Rasmussen

"C makes it easy to shoot yourself in the foot; C++ makes it harder,
but when you do, it blows away your whole leg." - Bjarne Stroustrup
-------------------------------------------------------------------
Fjern NOSPAM fra min adresse, for at sende mig en mail

---

Michael Rasmussen wrote in <pan.2002.12.07.14.54.39.333156@datanom.net>:
>>> Har lige læst beskrivelsen hos Pear og her fremgår det, at den
>>> som input tager en variabel,
>> Hvilken "den"?
> var_dump($db->query("UPDATE ..."));
> Det var ovenstående, jeg referede til.

var_dump? Den tager hvad som helst. Den har i hvert fald ikke brækket sig
over noget som helst jeg har givet den endnu.

> En kommentar til at PEAR::DB er et abstraktionslag. Det er vi helt
> enige om, men fordi en klasse er et abstraktionslag, betyder det
> ikke samtidig, at det ændrer på de underliggende funktioners
> returtype.

Det betyder i hvert fald, at dokumentationen for "de underliggende
funktioner" ikke kan bruges på abstraktionslaget.

Hele meningen med abstraktionslaget er jo, at det skal fungere anderledes.
Ellers ville det da være overflødigt. Det behøver godt nok ikke at være
*alt* der er anderledes. Men du argumenterede for abstraktionslagets
funktionalitet, med dokumentationen for de underliggende funktioner. Det
kan man ikke.

> Var det tilfældet, ville jeg mene, at abstraktionslaget
> var kodet forkert. En ting er at introducere nye funktioner/metoder,
> med vær deres egne returtyper, men at ændre på de indbyggede
> funktioners returtype, mener jeg, er farligt.

Jeg synes det virker fint. Mit problem her skyldtes udelukkende at der blev
returneret noget som *ikke* var et objekt..

> Så for at gøre en lang historie kort er jeg af den opfattelse, at
> var_dump forventer en type som indput*), hvorimod PEAR::DB returnerer
> objekter, og derfor vil var_dump udskrive ressourcens ID i stedet
> for.
>
> *) I PHP findes typen integer, real, string og array.

var_dump() kan sagtens klare mere end de nævnte typer. Prøv selv at lege med
det.
Giver man den fx. en ressource, så fortæller den at det er en ressource, og
giver id'en. Det fortæller vist også hvad det er for en slags ressource.
Giver man den et objekt, så giver den en rekursiv liste over alle felterne i
objektet. Prøv selv at fodre den med nogle af de forskellige objekter
PEAR:DB laver.

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

On Sat, 07 Dec 2002 16:37:08 +0100, Niels Andersen wrote:

> Det betyder i hvert fald, at dokumentationen for "de underliggende
> funktioner" ikke kan bruges på abstraktionslaget.
>
> Hele meningen med abstraktionslaget er jo, at det skal fungere
> anderledes. Ellers ville det da være overflødigt. Det behøver
> godt nok ikke at være *alt* der er anderledes. Men du argumenterede
> for abstraktionslagets funktionalitet, med dokumentationen for de
> underliggende funktioner. Det kan man ikke.
>
Her tror jeg, vi er uenige For mig betyder et abstraktionslag, at
tilgangen til funktioner/metoder gøres

1) transparent for brugerne.
2) Giver en ensartet implementation

>
> var_dump() kan sagtens klare mere end de nævnte typer. Prøv selv
> at lege med det.
> Giver man den fx. en ressource, så fortæller den at det er en
> ressource, og giver id'en. Det fortæller vist også hvad det er for
> en slags ressource. Giver man den et objekt, så giver den en
> rekursiv liste over alle felterne i objektet. Prøv selv at fodre
> den med nogle af de forskellige objekter PEAR:DB laver.
Ja, det lyder til, at funktionen har nogen spændende muligheder, så
jeg vil følge din opfordring.

--
Hilsen/Sincerely
Michael Rasmussen

"C makes it easy to shoot yourself in the foot; C++ makes it harder,
but when you do, it blows away your whole leg." - Bjarne Stroustrup
-------------------------------------------------------------------
Fjern NOSPAM fra min adresse, for at sende mig en mail

---

On Sat, 07 Dec 2002 17:03:43 +0100, Michael Rasmussen wrote:

[snip - hvad er abstraktion]

> 2) Giver en ensartet implementation

Det medfører jo også at der ændres på dels navne og dels retur-værdierne i
forhold til de eksisterende "lowlevel" PHP funktioner til det samme.

--
Christian Jørgensen | Do not look into the laser with remaining eye!
http://www.razor.dk |

---

Michael Rasmussen wrote in <pan.2002.12.07.16.03.41.473921@datanom.net>:
>> Hele meningen med abstraktionslaget er jo, at det skal fungere
>> anderledes.
[...]
> Her tror jeg, vi er uenige For mig betyder et abstraktionslag, at
> tilgangen til funktioner/metoder gøres
>
> 1) transparent for brugerne.
> 2) Giver en ensartet implementation

Det vil ofte også kræve ændringer i hvad der bliver returneret.
Fx. kan man ikke lave et db-abstraktionslag til php, uden at det må
returnere noget andet, end de "rå" funktioner gør.

Så vidt jeg husker vil fx. mysql_query returnere en mysql resource.
En af fordelene ved et db-abstraktionslag er, at man kun skal ændre i
abstrationslagets opsætning, for at skifte database. Fx. fra MySQL til
PostGreSQL. Men jeg vil tro at en mysql resource kun kan læses af
mysql-funktionerne.

Altså er abstraktionslaget nødt til at ændre både hvordan man kalder
databasen, samt hvad der kommer retur.
Og så fungerer det anderledes. Både hvordan man kalder databasen, hvordan
man giver den input (dvs. noget SQL og evt. nogle parametre) samt hvad der
kommer retur.

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

Michael Rasmussen wrote in <pan.2002.12.07.14.54.39.333156@datanom.net>:
> Så for at gøre en lang historie kort er jeg af den opfattelse, at
> var_dump forventer en type som indput*)
[...]
> *) I PHP findes typen integer, real, string og array.

Jeg måtte lige slå op, jeg har vist ikke læst i manualen om var_dump() i
flere år. :)

"This function returns structured information about one or more expressions
that includes its type and value."

Selv ifølge dokumentationen er det altså ikke en type den vil have, men et
udtryk. Og et udtryk, det er jo nærmest hvad som helst. :)

var_dump(5);
var_dump('test');
var_dump(echo('test'));
var_dump(fopen('sletmig','w')):

Den æder hvad som helst. :)
Men i de to sidste kan det godt være svært for en begynder at gennemskue
hvad der foregår. :)

--
Mvh.

Niels Andersen
(la nels. anersyn.)

---

Niels Andersen wrote:

>> Jeg får stadig bare int(1). ARGH! :)
>> var_dump($db->query("UPDATE temp SET word = word"));

....

> Det passer ikke lige med manualen, men det virker. Jeg laver nok en
> bug-report senere.

Mjoeh, det kommer an på hvor man kigger..

http://pear.php.net/manual/en/core.db.query.php siger:
Returns - resource - a new DB_Result or a DB_Error when fail

mens http://pear.php.net/manual/en/core.db.tut_query.php siger:
On succes you get DB_OK (predefined PEAR::DB constant) or when you set a
SELECT-statment a DB Result object.


--
Regards,
Nezar Nielsen

Worldfamous sheepherder.