Podrobné chybové hlášky pro PostgreSQL

Konečně jsem se dokopal a zkusil… výborný :)

Tvoji fičurku s rozšířeným error reportingem využiju jen v administračních toolech kde poznám, co je user chyba a co systémová. Ale s touhle dualitou chyb jsem se už také potýkal.

Dospěl jsem nakonec k tomu, že celou vrstvu vkládání, úprav a mazání mívám v databázi pomocí uložených procedur v jazyku Pl/PgSql. Např:

CREATE OR REPLACE FUNCTION "AddUser" ( pLogin varchar, pHeslo varchar ) RETURNS integer AS $body$
DECLARE
    idUser INTEGER;
BEGIN
    PERFORM 1 FROM user WHERE login = pLogin;
    IF FOUND THEN
        RAISE EXCEPTION 'Uživatel s loginem % již existuje.', pLogin;
    END IF;

    IF length(pHeslo) < 6 THEN
        RAISE EXCEPTION 'Heslo musí být dlouhé alespoň 6 znaků.';
    END IF;

    INSERT INTO user (login, password) VALUES (pLogin, pHeslo) RETURNING id INTO idUser;
    RAISE NOTICE 'Uživatel s loginem % založen jako UID(%).', pLogin, idUser;

    RETURN idUser;
END
$body$
LANGUAGE 'plpgsql'
VOLATILE
CALLED ON NULL INPUT
SECURITY INVOKER
COST 100;

Pro RAISE .... mám ještě proceduru, která zprávu formátuje jako USER_ERROR:Uživatel má duplicitní login... a to se v aplikaci už dobře odchytává.

V aplikaci pak volám jednoduše:

dibi::query( 'SELECT [AddUser]( %s, %s )', $login, $heslo );

Výhodou je, že při verzování zůstává vše pohoromadě. Každá procedura běží ve vlastní transakci takže zápis do více tabulek se dá dobře stornovat. A skvěle se dají hlídat hodnoty zapisované do databáze.

Nevýhod je také spousta, jako třeba sehnat hosting. Já mám vlastní servery, takže třeba tohle neřešim. Nebo migrace na jinou db je nemožná. Anebo jakákoliv změna počtu parametrů funkce většinou znamená změnu v databázi. Možná i nevýhody převažují, ale na tenhle typ práce s DB jsem si už hodně navyknul.