Discussion:
Postgres - własne komunikaty przy naruszeniu ograniczeń
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
Kacper Chrapa
2007-03-16 18:40:32 UTC
Permalink
Raw Message
Witam!

Jeśli mamy założone ograniczenia na kolumny w postgresie np. check ,to w
sytuacji ich naruszenia,postgres wyrzuca dosc lakoniczne i po angielsku( ;-) )
komunikaty - czyli np.(w wolnym tlumaczeniu) "odrzucono z powodu ograniczenia
jakies_ograniczenie".


Pytanie: czy można przy ograniczeniach zdefiniować własne komunikaty np.
"Operacja się nie powiodła - kod pocztowy powinien być w formacie nn-nnn." ?

Podobnie - czy można je zdefiniować przy naruszaniu więzów integralności -
np. "Nie mogę usunąć klienta,ponieważ złożył on zamówienia". ?

Chodzi oczywiście o to,aby na poziomie bazy kontrolować dane,a użytkownikowi
końcowemu(np. korzystajacemu z aplikacji www) przekazać czytelny komunikat,co
jest nie tak.

Wydaje się,że rozwiązaniem jest zastosowanie trygerów lub procedur
składowanych do odpowiednich operacji - przy każdej operacji walidujemy
dane i wyrzucamy np. notice czy raise z ladnym komunikatem,ktory trafia do
usera.
Jednak wtedy mamy do wyboru: albo zrezygnowac z ograniczen
i zapewnic je samemu przez odpowiednie funkcje(+ ograniczenie uprawnien do
tabel ) - albo dublowac walidacje w funkcjach i ograniczeniach,co wydaje sie
ze wplynie na wydajnosc (nie mowiac o podwojnej robocie przy jakichkolwiek
zmianach w logice).

A moze jest jakies trzecie rozwiazanie ? Jak wy tą kwestie rozwiązujecie?
Bede wdzieczny za sugestie :-)

Pozdrawiam,
Kacper
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
hubert depesz lubaczewski
2007-03-16 19:15:07 UTC
Permalink
Raw Message
Post by Kacper Chrapa
A moze jest jakies trzecie rozwiazanie ? Jak wy tą kwestie rozwiązujecie?
Bede wdzieczny za sugestie :-)
komunikatami dla klienta zajmuje sie aplikacja kliencka.
jesli uzytkownik koncowy *nie* korzysta z psql'a to tego typu komunikaty
nie wydają mi się celowe.

depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
Kacper Chrapa
2007-03-17 07:59:13 UTC
Permalink
Raw Message
Post by hubert depesz lubaczewski
komunikatami dla klienta zajmuje sie aplikacja kliencka.
jesli uzytkownik koncowy *nie* korzysta z psql'a to tego typu komunikaty
nie wydaj� mi si� celowe.
Hmm - z jednej strony tak.. z drugiej - chcialbym znaczna czesc logiki
aplikacji zapisac w plpgsql'u.Dlaczego?

Z zalozenia,z bazy danych bedzie korzystac wiele aplikacji:jedne
bezposrednio,a inne poprzez soap.

Jesli czesc logiki biznesowej oraz wiekszosc regul walidujacych umieszcze
w bazie,to bede mial dosc duza pewnosc,ze zadna z aplikacji nie naruszy
integralnosci calego systemu.

Pilnowanie integralnosci w bazie bedzie na 2 poziomach:
1.Co mozna,przy pomocy indeksow i ograniczen(format kodu,konta bank.,itd) -
* czyli dosc lakoniczne komunikaty dla
aplikacji klienckiej*.

2.Pozostale oraz wykonywanie dzialan powiazanych - w trygerach i
procedurach sklad.,
*czyli juz moge
dorzucic wlasne komunikaty*


I teraz - jesli baza danych pilnuje integralnosci ,to czy nie wydaje sie
sensowne zwolnienie z tej funkcji aplikacji klienckich(przynajmniej w pewnym
stopniu)?

Problem w tym,ze w takiej sytuacji,uzytkownik koncowy powinien dostac czytelny
komunikat,jesli walidacja czy inna operacja przeprowadzona przez baze sie nie
powiedzie.

Więc,moge albo np. zdefiniowac slownik z komunikatami(kom. bazy na odpowiedni
dla usera) i udostepnic go poszczegolnym aplikacjom klienckim,albo od razu
w bazie zdefiniowac czytelne komunikaty.

To drugie rozwiazanie wydaje mi sie lepsze:
1.Nie musze bawic sie w dodatkowe slowniki,ktore bedzie trzeba
aktualizowac.
Poza tym,zawsze nakladaja jakis narzut na wydajnosc(choc
oczywiscie,raczej znikomy i byc moze do pominiecia).

2.Ja dostane czytelniejsze komunikaty,gdy bede korzystal z psql'a ;-)

3.Architektura systemu wydaje sie bardziej przejrzysta i spojna:
Baza danych pilnuje integralnosci i informuje aplikacje klienckie(a te
uzytkownika),co zrobil nie tak (albo,ze wszystko poszlo ok).
Oczywiscie,na tyle,na ile jest w stanie.Reszta idzie na barki aplikacji.

Reasumujac - chcialbym znaczna czesc logiki systemu(a
dokladniej,poszczegolnych dzialan) scentralizowac w bazie danych.
I dodac do tego czytelne komunikaty.

Stad moje pytanie:-)

Pozdrowionka,
kacper
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
hubert depesz lubaczewski
2007-03-17 09:01:59 UTC
Permalink
Raw Message
Post by Kacper Chrapa
Hmm - z jednej strony tak.. z drugiej - chcialbym znaczna czesc logiki
aplikacji zapisac w plpgsql'u.Dlaczego?
no i dobrze, ale to niepowiązane.
Post by Kacper Chrapa
1.Nie musze bawic sie w dodatkowe slowniki,ktore bedzie trzeba
aktualizowac.
Poza tym,zawsze nakladaja jakis narzut na wydajnosc(choc
oczywiscie,raczej znikomy i byc moze do pominiecia).
jakie aktualizacje? możesz dostać informacje o "unique key violation",
"not null" i "foreign key".
to chyba nie za dużo jak na "słownik"?
Post by Kacper Chrapa
2.Ja dostane czytelniejsze komunikaty,gdy bede korzystal z psql'a ;-)
osoba grzebiąca po bazie sql'em nie powinna dostawać "tłumaczonych"
error-code'ów. bo np. nie zawierają całej informacji.

jeśli np. mam błąd w funkcji i ona się wywali to użytkownikowi
wyświetlę:
- aplikacja zachowała się w sposób nieoczekiwany. skontaktuj się z
twórcą. kod referencyjny błędu 0x0002;
ale jak pracuję bezpośrednio z psql'a to nie chcę takich "bzdurek" tylko
po prostu:
syntax error at line 9 in function bleble near "END;"
Post by Kacper Chrapa
Baza danych pilnuje integralnosci i informuje aplikacje klienckie(a te
uzytkownika),co zrobil nie tak (albo,ze wszystko poszlo ok).
Oczywiscie,na tyle,na ile jest w stanie.Reszta idzie na barki aplikacji.
sorry, ale to co piszesz nie ma sensu.
nigdy w życiu nie zanegowałbym celu trzymania logiki w bazie.
ale trzymanie logiki a "przyjazne" komunikaty błędów to zupełnie inne
sprawy.
więc nie sugeruj w postach, że sugeruję by logika była w aplikacji -
nigdy czegoś takiego nie robiłem i w przewidywalnej przeszłości nie
zrobię.

depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
Kacper Chrapa
2007-03-17 11:30:33 UTC
Permalink
Raw Message
Post by Kacper Chrapa
1.Nie musze bawic sie w dodatkowe slowniki,ktore bedzie trzeba
aktualizowac.
Poza tym,zawsze nakladaja jakis narzut na wydajnosc(choc
oczywiscie,raczej znikomy i byc moze do pominiecia).
jakie aktualizacje? moşesz dosta� informacje o "unique key violation",
"not null" i "foreign key".
to chyba nie za duşo jak na "s�ownik"?
hmm :-)

Nie to mam na mysli .Chodzi mi np. o cos takiego:

1.zakladam check() na kolumne kod_pocztowy.Wymuszam np. kod pocztowy w
formacie: nn-nnn . Jesli teraz nastapi proba naruszenia tego ograniczenia,
otrzymam od postgresa cos w stylu: "rejected due to CHECK constraint
klient_kod_pocztowy" .
Takich ograniczen jest wiecej.Wiec dla kazdego z nich musialbym napisac
oddzielna pozycje w "slowniku":
"rejected due to CHECK constraint klient_kod_pocztowy" -> "Nieprawidłowy kod
pocztowy.Proszę wprowadzić kod w formacie nn-nnn".

Moglbym to samo ograniczenie umiescic najpierw w aplikacji i tam
umiescic komunikat - ale jesli baza robi taka sama walidacje - to nie ma
koniecznosci(jak sie wydaje) jej dublowac.Wystarczy tutaj tylko wstepny filtr.
Post by Kacper Chrapa
2.Ja dostane czytelniejsze komunikaty,gdy bede korzystal z psql'a ;-)
osoba grzebi�ca po bazie sql'em nie powinna dostawa� "t�umaczonych"
error-code'ów. bo np. nie zawieraj� ca�ej informacji.
No tak.Jednak w powyzszym wypadku, programista musi i tak sprawdzic szczegoly
ograniczenia,zanim cokolwiek zrobi(przeciez nie zdejmie go od reki,nie
wiedzac,co dokladnie robi ).Sama nazwa i tak mu niewiele da
(notabene,faktycznie mozna ja podac w komunikacie "przyjaznym").
A ja chce dodac komunikaty glownie do takich przewidywalnych sytuacji.
je�li np. mam b��d w funkcji i ona si� wywali to uşytkownikowi
- aplikacja zachowa�a si� w sposób nieoczekiwany. skontaktuj si� z
twórc�. kod referencyjny b��du 0x0002;
ale jak pracuj� bezpo�rednio z psql'a to nie chc� takich "bzdurek" tylko
syntax error at line 9 in function bleble near "END;"
Masz racje.Mi chodzi jednak o komunikaty do sytuacji *przewidywalnych*,ze
znacznikiem np. "<info>.....</info>",zeby tylko takie trafily do usera koncowego.
A komunikat jak powyzej i tak nie powinien sie pojawic userowi - bo przeciez
do produkcyjnej wersji nie damy funkcji przed kompilacja
i dokladnym testem.A taki komunikat dostanie programista - i oczywiscie
powinno byc - tutaj sie zgadzam z Toba w 100%
Post by Kacper Chrapa
Baza danych pilnuje integralnosci i informuje aplikacje klienckie(a te
uzytkownika),co zrobil nie tak (albo,ze wszystko poszlo ok).
Oczywiscie,na tyle,na ile jest w stanie.Reszta idzie na barki aplikacji.
sorry, ale to co piszesz nie ma sensu.
nigdy w Ĺźyciu nie zanegowaĹ&#65533;bym celu trzymania logiki w bazie.
ale trzymanie logiki a "przyjazne" komunikaty bĹ&#65533;Ä&#65533;dĂłw to zupeĹ&#65533;nie inne
sprawy.
wiÄ&#65533;c nie sugeruj w postach, Ĺźe sugerujÄ&#65533; by logika byĹ&#65533;a w aplikacji -
nigdy czegoĹ&#65533; takiego nie robiĹ&#65533;em i w przewidywalnej przeszĹ&#65533;oĹ&#65533;ci nie
zrobiÄ&#65533;.
wcale tak nie sugeruje .Zdziwilbym sie,gdybys tak zasugerowal:-)

Kurcze,zgadzam sie z Toba w wiekszosci wypadkow.Moim celem jest poprostu
nastepujaca rzecz:
Chcialbym,zeby baza nie tylko pilnowala danych,ale tez czytelnie przekazywala
informacje uzytkownikom,czemu czegos nie pozwolila zrobic(a user np. niech
poda inne dane).
Jesli tak nie zrobie,to musze dodatkowo w aplikacji klienckiej umieszczac
dokladnie taka sama walidacje jak w bazie(albo wspomniany
"slownik").Zastanawiam sie po prostu,czy mozna tego uniknac.


Pozdrawiam,
Kacper
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
hubert depesz lubaczewski
2007-03-17 15:24:32 UTC
Permalink
Raw Message
Post by Kacper Chrapa
Jesli tak nie zrobie,to musze dodatkowo w aplikacji klienckiej umieszczac
dokladnie taka sama walidacje jak w bazie(albo wspomniany
"slownik").Zastanawiam sie po prostu,czy mozna tego uniknac.
uzywaj triggerów w pl/pgsql'u i rzucaj odpowiednie exceptiony.
ale to nie zmieny komunikatów w tych 3 sytuacjach o których mówiłem -
unique/ not null/ fkey.

depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
Kacper Chrapa
2007-03-18 10:18:16 UTC
Permalink
Raw Message
uzywaj triggerĂłw w pl/pgsql'u i rzucaj odpowiednie exceptiony.
ale to nie zmieny komunikatĂłw w tych 3 sytuacjach o ktĂłrych mĂłwiĹ&#65533;em -
unique/ not null/ fkey.
.Tak tez i zaczalem robic... trigger waliduje dane,i rzuca wyjatek...
Nawet sytuacje powyzej mozna w wiekszosci wypadkow przechwycic w ten sposob...

Tylko pojawia mi sie male pytanko ... jesli robie to tutaj...to postgres
robi to drugi raz przy samodzielnym sprawdzaniu ograniczen ... czyli - w
przyblizeniu oczywiscie - dla niego to dwa razy ta sama robota...;-)

Moze wiec w tej sytuacji zrezygnowac z ograniczen - a tylko zaimplementowac je
recznie w tryggerach?Niby trygger i tak sie powinien zawsze odpalac ,wiec
wszystko co trzeba sprawdzi...z drugiej strony - w koncu sa w bazie
mechanizmy,ktore sa dokladnie do tego przeznaczone,i jakos czuje "delikatny
opor";-) przed ich zignorowaniem(no i pewnie zwykle beda wydajniejsze).


Jednak,chyba faktycznie pojde w tym kierunku - zrezygnuje z ograniczen
i zaimplementuje je tylko w tryggerach.
Generalnie,integralnosc zostanie wymuszona,tylko moze nie do konca przy
uzyciu tych narzedzi,ktore intuicyjnie wydaja sie optymalne...


Pozdrawiam i dzieki za wskazowki,
kacper
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
sg
2007-03-18 10:47:34 UTC
Permalink
Raw Message
Post by Kacper Chrapa
Jednak,chyba faktycznie pojde w tym kierunku - zrezygnuje z ograniczen
i zaimplementuje je tylko w tryggerach.
Generalnie,integralnosc zostanie wymuszona,tylko moze nie do konca przy
uzyciu tych narzedzi,ktore intuicyjnie wydaja sie optymalne...
yyy, czyli takie ograniczenia jak unique chcesz robić w triggerze?
hubert depesz lubaczewski
2007-03-18 11:32:12 UTC
Permalink
Raw Message
Post by Kacper Chrapa
Jednak,chyba faktycznie pojde w tym kierunku - zrezygnuje z ograniczen
i zaimplementuje je tylko w tryggerach.
Generalnie,integralnosc zostanie wymuszona,tylko moze nie do konca przy
uzyciu tych narzedzi,ktore intuicyjnie wydaja sie optymalne...
pomysł mi się nie podoba.
po pierwsze - np. fkey implementowany w pl/pgsql'u jest o *rzędy*
wielkości wolniejszy niż natywny.
po drugie - jakoś podskórnie czuję, że są edge-case'y gdzie pewnych
rzeczy w własnych triggerach nie zrobisz lub nie zrobisz prosto.
nie jestem w stanie powiedzieć o co mi chodzi - to tylko takie
przeczucie.

depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
Sławomir Szyszło
2007-03-17 16:11:21 UTC
Permalink
Raw Message
Dnia Sat, 17 Mar 2007 11:30:33 +0000 (UTC), "Kacper Chrapa"
Post by Kacper Chrapa
Kurcze,zgadzam sie z Toba w wiekszosci wypadkow.Moim celem jest poprostu
Chcialbym,zeby baza nie tylko pilnowala danych,ale tez czytelnie przekazywala
informacje uzytkownikom,czemu czegos nie pozwolila zrobic(a user np. niech
poda inne dane).
Tak naprawdę wystarczy, jeśli baza potrafi przekazać nazwę constrainta przy
zgłoszeniu błędu. Wtedy w aplikacji przechwytujesz tą nazwę i przekładasz na
język zrozumiały przez użytkownika. Czy PostgreSQL potrafi to przekazać?
--
Sławomir Szyszło mailto:***@poczta.onet.pl
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?group=pl.comp.bazy-danych
hubert depesz lubaczewski
2007-03-17 19:05:13 UTC
Permalink
Raw Message
Post by Sławomir Szyszło
język zrozumiały przez użytkownika. Czy PostgreSQL potrafi to przekazać?
tak:
#v+
# create table test (x int4);
CREATE TABLE

# alter table test add constraint test_test check (x > 0);
ALTER TABLE

# insert into test (x) values (0);
ERROR: new row for relation "test" violates check constraint "test_test"
#v-

depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
Filip Rembiałkowski
2007-03-19 14:27:44 UTC
Permalink
Raw Message
Post by Kacper Chrapa
Witam!
Jeśli mamy założone ograniczenia na kolumny w postgresie np. check ,to w
sytuacji ich naruszenia,postgres wyrzuca dosc lakoniczne i po angielsku( ;-) )
komunikaty - czyli np.(w wolnym tlumaczeniu) "odrzucono z powodu ograniczenia
jakies_ograniczenie".
Pytanie: czy można przy ograniczeniach zdefiniować własne komunikaty np.
filip=> create function t_ok(in_id int) returns boolean as $$
begin
if not in_id > 0 then
raise exception 'id must be positive';
end if;
return true;
end;
$$ language plpgsql strict;
CREATE FUNCTION
filip=> create table t ( id int check( t_ok(id) ) );
CREATE TABLE
filip=> insert into t(id)select 0;
ERROR: id must be positive

Loading...