[Zope-DB] Re: ZPsycopgDA (version 1.0.13) problems

Federico Di Gregorio fog@debian.org
20 Jan 2003 14:25:54 +0100


--=-Qj02o4DxLD9dHlIB2l5Q
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Il lun, 2003-01-20 alle 13:20, Dieter Maurer ha scritto:
> Dear Michele and Federico,
>=20
> we are using your ZPsycopgDA (1.0.13) and encountered the following
> problems:
>=20
>   *  "db.DA.query" catches "psycopg.ProgrammingError" and
>      checks against "ERROR:  Can't serialize access due to concurrent upd=
ate".
>=20
>      However, our Postgres intallation reports this problem as
>      "psycopg.IntegrityError".

yesss. it was change from ProgrammingError to IntegrityError but not in
ZPsycopgda. this is a bug, will be fixed.

>=20
>      I suggest to add that in the "except" clause:
>=20
>        except (psycopg.ProgrammingError,psycopg.IntegrityError), perr:
>=20
>=20
>   *  The code uses "raise sys.exc_type, ...". However, this is
>      not thread safe. Suggest to use "raise" instead.

just raise? it will use the current exception stack? very nice, i did
not know about that. will be in 1.0.14.1.

>=20
>   *  The error handling in "db.DA.query" is inhomogenous (and irrational)=
:
>=20
>       - "InterfaceError" checks for "self.db" which is unnecessary,
>         because we just used it (therefore it must exist).
>=20
>       - "OperationalError" does not check for "self.db" but wraps
>         the close/reopen in a redundant "try: ... except: raise".
>=20
>      Suggest to fold and unify handling for "OperationalError" and
>      "InterfaceError":
>=20
>        except (psycopg.OperationalError, psycopg.InterfaceError), err:
>            del c; del self.db # close
> 	   self.db=3D self.connect(self.connection) # reopen
> 	   return self.query(query_string,max_rows) # retry

ok. but i'll leave the self.db check there because when it was added
there was a reason and i don't want to break a stable version just by
removing code that seems wrong and in the worst case just add a function
call.

>   *  "max_rows=3D=3D0" is interpreted as to not return results at all.
>      It seems more consistent with other use of the value "0"
>      to interpret it as "no restriction"

ok. i'll just make sure zope does not assign a different meaning to 0.

>   *  I have added error logging to "db.DA.query" such that one can better
>      understand what goes wrong.

can you send patches?

>   *  I have been unable to understand the motivation for the "failure"
>      use in "db.DA.query".

if a generic (not catched) error happens, we try to close and reopen the
connection a number of times before returning an error. this code was
copied from ZOracle and i never been completely satisfacted by it.

> Besides, we still have a problem not yet understood:
>=20
>    Sometimes, we seem to get empty result sets from Postgres (where we kn=
ow,
>    the result set should be non-empty).
>    We are still investigating this problem.

good. if you want my help, just send me any relevant code and data to
reproduce the problem.

thank you very much for your work on ZPsycopgDA, it is not my favourite
piece of software lately..

/federico


--=-Qj02o4DxLD9dHlIB2l5Q
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+K/jivcCgrgZGjesRAuNGAJ9nuXLh5BLxHBOPP8c1zJZEWuYgEQCfViv/
BO0y55tSnz1vGLvMqyMgqyQ=
=owMp
-----END PGP SIGNATURE-----

--=-Qj02o4DxLD9dHlIB2l5Q--