[PostgreSQL/PHP] Probleem met sql-query in script

[bokkiewok]

Hoi,

Ik zit met een probleem waar ik zelf niet uitkom.
De situatie:

Een tabel met gegevens over projecten. Projecten worden voorzien van een id, dit is een integer.
Ik wil vanuit een form de tabel kunnen uitbreiden met nieuwe projecten.
Dat is op zich geen probleem, ware het niet dat een query in het script een andere output geeft dan in de database zelf. Het betreft een query om de hoogste integer van de id-kolom te vinden.
Op de psql command line gaat dit commando goed. Zoda ik het in php in een script giet, dan krijg ik compleet andere output. En die output kan ik niet verklaren.
De query in psql:
SQL:

select max(p_id) from projects;
 max
-----
  18
(1 row)

Deze geeft dus de juiste waarde terug, 18.

Nu in het script:
PHP:

$q_id = "select max(p_id) from projects";
$qr_id = pg_query($q_id);
$p_id = $qr_id + 1;

Ik verwacht dus in $qr_id het getal 18, en deze wil ik met 1 ophogen voor het volgende ID van een nieuw project, wat ik met een insert in wil geven. Als ik $qr_id echo krijg ik echter "Resource id #3" terug. Dat is niet wat ik verwacht.
Zie ik iets over het hoofd ? Zo ja, wat ?

[Tjolk]

De output van pg_query() is een resource. Je zult $qr_id dus nog moeten fetchen met bijvoorbeeld pg_fetch_result() om er een string van te maken.

Tjolk wijzigde deze reactie 23-10-2009 11:34 (5%)

[dev10]

Je krijgt nu een resultset terug, die je even moet omzetten door middel van pg_fetch_result().

edit:
Met ^^

dev10 wijzigde deze reactie 23-10-2009 11:34 (14%)

[Woy]

Je snapt ook dat het uidelen van ID's op deze manier niet echt handig is. Het is wachten op problemen.

Stel er worden 2 requests tegelijk gedaan, request 1 vraag het hoogste ID op, tegelijkertijd vraag request 2 het ID op. Dan verhogen ze beide het ID met 1, en proberen dus met hetzelfde ID te inserten.

Je kunt beter kijken naar de faciliteiten die de database zelf bied. Ik ken PostgreSQL niet, maar vaak is er iets als een Auto Increment kolom of iets van Sequences die je hiervoor kunt gebruiken.

quote:

Ger schreef op vrijdag 23 oktober 2009 @ 11:34:
Je zult $qr_id dus nog moeten fetchen met bijvoorbeeld pg_fetch_result() om er een string van te maken.

Echter wil je er helemaal geen string van maken, want het is een numerieke waarde die je selecteert

Woy wijzigde deze reactie 23-10-2009 11:39 (23%)

[JanDM]

quote:

bokkiewok schreef op vrijdag 23 oktober 2009 @ 11:30:
Ik verwacht dus in $qr_id het getal 18, en deze wil ik met 1 ophogen voor het volgende ID van een nieuw project, wat ik met een insert in wil geven.

Wat als twee gebruikers tegelijk een project toevoegen? Dan heb je kans dat ze hetzelfde id terugkrijgen en allebei proberen een insert met $id+1 te doen.

Niet doen dus. PostgreSQL kan automatisch het id-veld invullen. Dat is veiliger en minder werk

edit: wat ^^ zegt dus.

JanDM wijzigde deze reactie 23-10-2009 11:42 (10%)

[bokkiewok]

quote:

Woy schreef op vrijdag 23 oktober 2009 @ 11:37:
Je snapt ook dat het uidelen van ID's op deze manier niet echt handig is. Het is wachten op problemen.

Stel er worden 2 requests tegelijk gedaan, request 1 vraag het hoogste ID op, tegelijkertijd vraag request 2 het ID op. Dan verhogen ze beide het ID met 1, en proberen dus met hetzelfde ID te inserten.

Je kunt beter kijken naar de faciliteiten die de database zelf bied. Ik ken PostgreSQL niet, maar vaak is er iets als een Auto Increment kolom of iets van Sequences die je hiervoor kunt gebruiken.

[...]

Echter wil je er helemaal geen string van maken, want het is een numerieke waarde die je selecteert

Klopt. Echter, deze database beheer ik zelf, hij word door anderen gebruikt om wat data aan de hand van wat views te bekijken. De mutaties op de tabel zijn klein, en worden door mij uitgevoerd. Ik ben er dus niet bang voor dat er 2 requests tegelijk worden gedaan.

Maar je hebt wel gelijk dat het een numerieke waarde moet zijn. Eens gaan uitzoeken hoe dat in zijn werk gaat.

bokkiewok wijzigde deze reactie 23-10-2009 11:44 (5%)

[Woy]

quote:

bokkiewok schreef op vrijdag 23 oktober 2009 @ 11:43:
[...]
Klopt. Echter, deze database beheer ik zelf, hij word door anderen gebruikt om wat data aan de hand van wat views te bekijken. De mutaties op de tabel zijn klein, en worden door mij uitgevoerd. Ik ben er dus niet bang voor dat er 2 requests tegelijk worden gedaan.

Dat is natuurlijk geen reden om het dan maar op een slechte manier aan te pakken. Er kunnen best redenen zijn waarom je je ID generatie in je applicatie wilt doen, maar als je geen goede reden hebt, moet je het gewoon aan je database overlaten. Je voorkomt dan gewoon problemen.

En het feit dat je er geen problemen mee verwacht is geen goede reden

[UltimateB]

Een tip bokkiework, als je niet zeker bent van de return van een functie gebruik dan var_dump($mVar); om te kijken wat erin zit. Scheelt een hoop tijd

[cariolive23]

Ga nooit met MAX() het hoogste id ophalen om daarmee een nieuw id aan te "kunnen" maken, dat gaat grote problemen opleveren. PostgreSQL (en bv. ook Oracle) gebruikt sequences, ga die dan ook gebruiken, ze zijn er niet voor niets.
SQL:

CREATE TABLE foo(
id SERIAL PRIMARY KEY,
content TEXT
);

INSERT INTO foo(content) VALUES('bar') RETURNING id;

Met deze opzet zal PostgreSQL zelf een sequence aanmaken en deze als default waarde aanroepen wanneer er een nieuw record in de tabel wordt gezet. Wanneer je dan een insert doet, krijg je het aangemaakte id als antwoord retour. De insert moet je dus net zoals een select keurig gaan fetchen en dan krijg je keurig antwoord op de vraag welk id is aangemaakt.

Uiteraard kun je ook vooraf al met NEXTVAL() de volgende waarde voor het id opvragen en deze in de insert zetten, net wat je handiger vindt.

Ps. RETURNING bestaat sinds versie 8.2, mocht je dus met een nog oudere versie aan de slag gaan, zal het niet werken en moet je wel met NEXTVAL() aan de slag wanneer je vooraf het id wilt weten. Achteraf kun je het id opvragen met LASTVAL(), zie ook de handleiding hoofdstuk 9.