🚀 go-pugleaf

Krzysztof Kaczkowski <krzysztof@py142.wroclaw.sdi.tpnet.pl> wrote:
> Zastanawiam sie nad wyborem mechanizmu dost�pu do bazy danych postgresql i
> mam wlasnie dylemat ktora z metod wybra� DB API2.0 czy wrapera na libpq,
> dorad�cie cos jak mo�ecie.

Wiem, sam mam czasami ten dylemat.  Przez p�tora roku u�ywa�em
wrappera do libpq, a potem przez kolejne p�tora DBI 2.0 -- to drugie
rozwi�zanie wydaje si� jednak lepsze do wi�kszo�ci zastosowa� i jest
jednak bardziej wysokopoziomowe.  Poza tym dzi�ki temu �atwiej jest
przenie�� program na inny system bazodanowy, gdy zajdzie taka
potrzeba.

Je�eli korzystasz z pyPgSQL to mo�esz zawsze zrobi� "mix" obydwu
podej��, czyli generalnie korzysta� z DBI, a od czasu do czasu
odwo�ywa� si� do libpq, czyli np.:

	from pyPgSQL import PgSQL
	conn = PgSQL.connect(opcje)
	cur = conn.cursor()
	cur.execute("zapytanie SQL przez DBI")
	conn.conn.query("zapytanie SQL przez libpq")

po prostu obiekt opisuj�cy po��czenie przez libpq jest dost�pny jako
atrybut conn obiektu opisuj�cego po��czenie przez PgSQL.

Jakby� mia� jeszcze jakie� pytania to pisz.

Pozdrawiam!

--
Adam Buraczewski <adamb@polbox.pl> * Linux registered user #165585
GCS/TW d- s-:+>+:- a- C+++(++++) UL++++$ P++ L++++ E++ W+ N++ o? K? w--
O M- V- PS+ !PE Y PGP+ t+ 5 X+ R tv- b+ DI? D G++ e+++>++++ h r+>++ y?

Dzi�ki, ale to nie rozwiewa moich w�tpliwosci ;)

Krzysztof Kaczkowski <krzysztof@py142.wroclaw.sdi.tpnet.pl> wrote:
> Dzi�ki, ale to nie rozwiewa moich w�tpliwosci ;)

Mo�e to jasno nie wynika�o z mojego postu, ale zdecydowanie polecam
u�ycie DBI :^)  Dzi�ki DBI w postaci PgSQL z pyPgSQL masz:

- lepsz� obs�ug� typ�w NUMERIC, DATE, TIME, TIMESTAMP, BOOLEAN, BIGINT
  itp. ni� z u�yciem libpq (pyPgSQL ma w�asne klasy do obs�ugi tych
  typ�w, a w libpq to wszystko jest obs�ugiwane tekstowo),

- wygodn� obs�ug� warto�ci NULL, zar�wno przekazanej jako parametr do
  execute() jak w zwracanej przez fetchone() i fetchall() (u�ywasz
  Pythonowej warto�ci None, kt�ra jest przekazywana do Postgresa jako
  NULL a przy odczytywaniu wynik�w NULL jest konwertowane na None),

- dost�p do kolumn zwracanych przez fetchone()/fetchall() po nazwie (a
  nie tylko po indeksie, jak w przypadku libpq),

- automatyczne escape'owanie napis�w przekazywanych do execute() (nie
  musisz si� martwi� o apostrofy i inne znaki specjalne w napisach),

- wewn�trzne wykorzystanie postgresowych kursor�w, gdy polecenie
  przekazane do execute() to pojedy�cza instrukcja SELECT,

- mapowanie b�ed�w Postgresa na standardowe wyj�tki DBI,

- mo�liwo�� �atwej przesiadki na inne modu�y, takie jak PoPy, psycopg
  czy PyGreSQL gdyby pyPgSQL okaza� si� niewystarczaj�cy lub przesta�
  by� rozwijany (obecnie pyPgSQL jest najlepszy, ale tworzy si� nowy
  front z po��czenia PoPy z PyGreSQL, by� mo�e warto b�dzie si�
  przesi���).

To chyba najwa�niejsze zalety.  A jakby� zapragn�� wykorzysta� libpq,
to zawsze mo�esz si� odwo�a� do atrybutu conn.

Pozdrawiam!

--
Adam Buraczewski <adamb@polbox.pl> * Linux registered user #165585
GCS/TW d- s-:+>+:- a- C+++(++++) UL++++$ P++ L++++ E++ W+ N++ o? K? w--
O M- V- PS+ !PE Y PGP+ t+ 5 X+ R tv- b+ DI? D G++ e+++>++++ h r+>++ y?

> Mo�e to jasno nie wynika�o z mojego postu, ale zdecydowanie polecam
> u�ycie DBI :^)  Dzi�ki DBI w postaci PgSQL z pyPgSQL masz:
Wynika�o jasno, ale brakowa�o tej pewno�ci co teraz ;)

>   typ�w, a w libpq to wszystko jest obs�ugiwane tekstowo),
Chocia� nie do ko�ca, troch� si� zdziwi�em gdy w�a�nie libpq w pyPgSQL
zwr�ci�o mi cos innego niz string.

...

Wi�c czuje si� przekonany do DB API :) Dzi�ki.