[Postgresql/CVS] syntax controle *

[JaQ]

Soms heb je het druk, soms heb je het zelfs zo druk dat je mensen in gaat huren om je te helpen met het schrijven van code voor je postgresql database. Een gevolg daarvan is dat je deze mensen toegang moet geven tot je cvs tree en dat er dus nieuwe stukken code worden toegevoegd / bestaande code wordt geupdate.

Zoals iedereen snapt doe ik het liefst alles zelf, want dan weet ik zeker dat elk stuk code gecontroleerd en gestest is voordat het gecommit wordt in cvs, maar soms red je dat gewoon niet meer. Elk stuk code wat een ander schrijft controleren en zelf testen is me echter wat te veel werk. (we hebben het over 250 + plpgsql functies, straks groeiend tot een 1000 functies).

Nu weet ik toevallig dat je o.a. met perl en php bepaalde tests automagisch kan laten uitvoeren op code die in je cvs worden gesubmit. Dat lijkt me in deze ook meer dan handig (zodat ik in ieder geval zeker weet dat de syntax van de gesubmitte code op orde is). Over het algemeen bestaan deze test uit het aanroepen van de code om dan te controleren of de parser niet knalt (en dan de eventuele foutmelding retourneren).

Met plpgsql is dit echter niet zo heel erg gemakkelijk, aangezien je zo ongeveer alles in een postgresql functie kan zetten wat je wilt (daarmee bedoel ik dus echt complete onzin), maar je kan toch de functie installeren. (en gewoon het script postgresql in drukken is dus niet genoeg). Moraal: een pre-parse engine die de syntax van de code controleerd is handig, of beter gezegt: noodzaak.

Nu ben ik eens gaan zoeken naar een progsel dat dit kan, maar om een of andere reden ben ik dat tot op heden nog niet tegen gekomen. Is er iemand die een progsel gebruikt of kent dat dit kan, of kan ik perl-magic gaan maken die syntax van plpgsql in een script gaat controleren?

[JaQ]

kick... (ja ja, 24 uur en 6 minuten )

Ik heb helaas tot op heden nog steeds niet kunnen vinden en ben langzamerhand maar eens begonnen aan wat perl + shell scripts die dit voor mij gaan doen. Wordt alleen wel een flinke klus volgens mij..

[ACM]

je zou ook een test-postgres op kunnen zetten (of een testdb in je bestaande postgres) en daar gewoon die nieuwe functie in inladen.

Uiteraard moet je hem dan nog zien te executen, maar als je per functie een paar testparameters + resultaten opgeeft zou dat opzich wel te doen moeten zijn.

Dan heb je een beetje wat ik vrij vaak als "testcode" heb gezien, namelijk gewoon de boel compileren en op een vaste dataset controleren of het hetzelfde resultaat geeft als verwacht

't Is echter wel aardig wat werk om op te zetten, maar zou in theorie verder compleet te automatiseren moeten zijn.

[JaQ]

ACM schreef op 07 August 2003 @ 11:45:
je zou ook een test-postgres op kunnen zetten (of een testdb in je bestaande postgres) en daar gewoon die nieuwe functie in inladen.

Uiteraard moet je hem dan nog zien te executen, maar als je per functie een paar testparameters + resultaten opgeeft zou dat opzich wel te doen moeten zijn.

Dan heb je een beetje wat ik vrij vaak als "testcode" heb gezien, namelijk gewoon de boel compileren en op een vaste dataset controleren of het hetzelfde resultaat geeft als verwacht

't Is echter wel aardig wat werk om op te zetten, maar zou in theorie verder compleet te automatiseren moeten zijn.

Op zich gebruik ik al een php testsuite, die netjes kijkt of de functie compileerd (met verwachte output en zo, feitenlijk dus alles behalve ERROR:). Die controleerd dus al of de "create or replace function" syntax correct is. Mijn zakenpartner had die in elkaar gefietst voor het controleren van php code, ff "lenen" en verbouwen deed wonderen in deze. Die test-suite maakt gebruik van PEAR, op zich werk dat wel aardig charmant, maar dan moet ik nog steeds voor elke functie een testscript maken (m.b.v. wat per-magic of zo.)

Zo'n testscript ziet er ongeveer zo uit:

code:

--TEST--
cdp: appDb bl/relations/contact_types.sql
--FILE--
<?php

    $day = strftime('%j');
    $sqldir = dirname(__FILE__) . "/../../../db/psql";
    $dbname = 'cdp_test_' . $day;

    echo "trying bl/relations/contact_types.sql: ";

    if (exec("psql -U cvsweb $dbname < $sqldir/bl/relations/contact_types.sql"))
    {
        echo "success.\n";
    }
    else
    {
        echo "failed.\n";
    }

?>
--EXPECT--
trying bl/relations/contact_types.sql: NOTICE:  relation.contact_types.id%TYPE converted to integer
NOTICE:  relation.contact_types.description%TYPE converted to character varying
NOTICE:  application.users.id%TYPE converted to integer
NOTICE:  relation.contact_types.description%TYPE converted to character varying
NOTICE:  application.users.id%TYPE converted to integer
NOTICE:  relation.contact_types.id%TYPE converted to integer
NOTICE:  relation.contact_types.description%TYPE converted to character varying
NOTICE:  application.users.id%TYPE converted to integer
NOTICE:  relation.contact_types.id%TYPE converted to integer
success.

Op zich is dat dus prima, maar dat verteld me dus niet of de logica in de functie correct is. Het probleem zit m erin dat ik dus voor een onwijze lading data dan testparameters moet gaan maken. Dat is gewoon niet grappig meer (denk aan een week werk op zichzelf), daarom wou ik dus kijken of er een "syntax-check" tool is.

Maar goed, als die er niet is, wordt het dus tijd voor mijn eerste gpl programma (tenminste, ik denk dat als ik een stel werkende set scripts maak, dat er ongetwijfeld meer mensen zijn die daar in geinteresseerd zijn)