headers
Federico Di Gregorio | 15 Oct 2002 17:51
Favicon
Gravatar

can't commit on error

mm.. sorry for being a little bit OT, but i am sure there are a lot of
pg gurus out there.. anyway, around 1.0.12 i removed the
auto-rollback-on-error limitation from psycopg and done some tests. if i
remember correctly i would be able to .commit() after an error and save
the data inserted until then. apparently in 7.2.2 this does not work
anymore. any ideas? did pg changed? i have a very bad memory?

--

-- 
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fog@...
INIT.D Developer                                           fog@...
  99.99999999999999999999% still isn't 100% but sometimes suffice. -- Me
Permalink | Reply | 0 comments |
headers
Edmund Lian | 16 Oct 2002 11:06

Exception handling

Hi All,

I notice that psycopg throws the ProgrammingError exception for things like
attempts to insert duplicate keys into tables, etc. I know this is
specified in the DB API 2 spec, but wouldn't it be much better/more helpful
if it threw more specific exceptions like DuplicateKeyError, etc.?

This actually raises a broader question--how can does one go about coding
exception handlers to catch specific problems like duplicate key errors,
referential integrity constraint errors in a DB independent way given that
the DB API 2 spec lacks more specific exception classes?

...Edmund.
Permalink | Reply | 2 comments |
headers
Federico Di Gregorio | 16 Oct 2002 21:00
Favicon
Gravatar

Re: Exception handling

Il mer, 2002-10-16 alle 11:06, Edmund Lian ha scritto:
> Hi All,
> 
> I notice that psycopg throws the ProgrammingError exception for things like
> attempts to insert duplicate keys into tables, etc. I know this is
> specified in the DB API 2 spec, but wouldn't it be much better/more helpful
> if it threw more specific exceptions like DuplicateKeyError, etc.?
> 
> This actually raises a broader question--how can does one go about coding
> exception handlers to catch specific problems like duplicate key errors,
> referential integrity constraint errors in a DB independent way given that
> the DB API 2 spec lacks more specific exception classes?

psycopg already raise IntegrityError. if you think it should raise other
errors, please send a mapping "postgres error" <-> dbapi exception. but
i won't add new exceptions outside of dbapi, the situation is already
enough complicated this way.

--

-- 
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fog@...
INIT.D Developer                                           fog@...
                           Don't dream it. Be it. -- Dr. Frank'n'further
Permalink | Reply | 1 comment |
headers
Edmund Lian | 17 Oct 2002 07:56

Re: Exception handling


On 10/17/2002 03:00:11 AM Federico wrote:

>psycopg already raise IntegrityError. if you think it should raise other
>errors, please send a mapping "postgres error" <-> dbapi exception. but
>i won't add new exceptions outside of dbapi, the situation is already
>enough complicated this way.

The DB API does offer the possibility of raising errors that are subclasses
of the mandatory ones, so you'd not be operating outside the DB API spec.
However, there's not much point your doing so since the resulting code to
catch any new exceptions would not be generalizable to the other DB
modules. The DB API spec is really lacking in this respect.

...Edmund.
Permalink | Reply | 1 comment |
headers
Federico Di Gregorio | 17 Oct 2002 09:53
Favicon
Gravatar

Re: Exception handling

Il gio, 2002-10-17 alle 07:56, Edmund Lian ha scritto:
> 
> On 10/17/2002 03:00:11 AM Federico wrote:
> 
> >psycopg already raise IntegrityError. if you think it should raise other
> >errors, please send a mapping "postgres error" <-> dbapi exception. but
> >i won't add new exceptions outside of dbapi, the situation is already
> >enough complicated this way.
> 
> The DB API does offer the possibility of raising errors that are subclasses
> of the mandatory ones, so you'd not be operating outside the DB API spec.
> However, there's not much point your doing so since the resulting code to
> catch any new exceptions would not be generalizable to the other DB
> modules. The DB API spec is really lacking in this respect.

agreed. anyway is someone wants a better mapping, just send it to me.

--

-- 
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fog@...
INIT.D Developer                                           fog@...
                             Best friends are often failed lovers. -- Me
Permalink | Reply | 0 comments |
headers
Federico Di Gregorio | 17 Oct 2002 10:18
Favicon
Gravatar

INFO: arch repository for psycopg 1.1

hi *,

the arch repository (via ftp) for psycopg 1.1 is up and working. i will
probably move psycopg 1.0 there too first or later. psycopg 1.1is about
to be released, featuring the COPY FROM/COPY TO patches and some other
little fixes. current stable version of psycopg is still 1.0.12, but 1.1
will replace it soon, i hope.

here is the information required to access the arch repo:

arch@...
	ftp://arch:arch@.../{main}

$ larch get psycopg--stable--1.1

snapshots and packages are still available thru:

	http://initd.org/pub/software/psycopg

have fun,
federico

--

-- 
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fog@...
INIT.D Developer                                           fog@...
                             Best friends are often failed lovers. -- Me
Permalink | Reply | 0 comments |
headers
Joel Rodrigues | 17 Oct 2002 10:49

Re: Exception handling

On Thursday, October 17, 2002, at 12:30 , Federico Di Gregorio wrote:

> Il mer, 2002-10-16 alle 11:06, Edmund Lian ha scritto:
>> Hi All,
>>
>> I notice that psycopg throws the ProgrammingError exception 
>> for things like
>> attempts to insert duplicate keys into tables, etc. I know this is
>> specified in the DB API 2 spec, but wouldn't it be much 
>> better/more helpful
>> if it threw more specific exceptions like DuplicateKeyError, etc.?
>>
>> This actually raises a broader question--how can does one go 
>> about coding
>> exception handlers to catch specific problems like duplicate 
>> key errors,
>> referential integrity constraint errors in a DB independent 
>> way given that
>> the DB API 2 spec lacks more specific exception classes?
>
> psycopg already raise IntegrityError. if you think it should 
> raise other
> errors, please send a mapping "postgres error" <-> dbapi exception. but
> i won't add new exceptions outside of dbapi, the situation is already
> enough complicated this way.
>

So the novice asks, "...how does one go about coding exception 
handlers to catch specific problems...", with what's available ?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Gollop | 17 Oct 2002 17:55

Can't serialize access due to concurrent update - but why?

I am occasionally getting this error

psycopg.ProgrammingError: ERROR:  Can't serialize access due to concurrent
update

Just very occasionally this happens with updates, but what is causing it?
There is only a single cursor object, and no other processes updating the
database.

Psycopg version 1.08

Julian Gollop
Codo Technologies ltd.
www.codotech.com
www.lasersquadnemesis.com
Permalink | Reply | 0 comments |
headers
Edmund Lian | 18 Oct 2002 03:18

Re: Exception handling


On 10/17/2002 04:49:44 PM Joel wrote:

>Here are some ideas I scavenged from various tutorials, etc. Of
>course most (all ?) articles only care about MySQL. The examples
>included with psycopg don't demonstrate exception handling with
>any sophistication. My success so far has only proved useful for
>debugging CGI scripts, rather than returning more useful error
>messages to a user, which I what I'd like to do without having
>to recode in the script all the error/integrity/etc. checking
>and that's already in the PostgreSQL database.

This is the crux of the problem with the lack of more specific exceptions,
the thing that is making me pull my hair out. With more specific
exceptions, one could just try to execute say, an insert statement, and
deal with say, duplicate key errors if an exception occurs. Without having
specific exceptions, you'd basically have to test for the existence of a
duplicate key first, then do the insert if no duplicate is found. One SQL
statement morphs into two (or more if the statements must be wrapped in a
transaction), and integrity constraints get duplicated in code. How awful
is this? I'm really bummed out about this. As you say, we might as well all
be using MySQL if we have to do this. Gag.

...Edmund.
Permalink | Reply | 10 comments |
headers
Federico Di Gregorio | 18 Oct 2002 10:19
Favicon
Gravatar

Re: Exception handling

Il ven, 2002-10-18 alle 03:18, Edmund Lian ha scritto:
> 
> On 10/17/2002 04:49:44 PM Joel wrote:
> 
> >Here are some ideas I scavenged from various tutorials, etc. Of
> >course most (all ?) articles only care about MySQL. The examples
> >included with psycopg don't demonstrate exception handling with
> >any sophistication. My success so far has only proved useful for
> >debugging CGI scripts, rather than returning more useful error
> >messages to a user, which I what I'd like to do without having
> >to recode in the script all the error/integrity/etc. checking
> >and that's already in the PostgreSQL database.
> 
> This is the crux of the problem with the lack of more specific exceptions,
> the thing that is making me pull my hair out. With more specific
> exceptions, one could just try to execute say, an insert statement, and
> deal with say, duplicate key errors if an exception occurs. Without having
> specific exceptions, you'd basically have to test for the existence of a
> duplicate key first, then do the insert if no duplicate is found. One SQL
> statement morphs into two (or more if the statements must be wrapped in a
> transaction), and integrity constraints get duplicated in code. How awful
> is this? I'm really bummed out about this. As you say, we might as well all
> be using MySQL if we have to do this. Gag.

ok. i think we *can* insert some more specific exceptions after all. now
a quick question: if you do INSERT .. INSERT .. INSERT and than you get
a IntegrityError (duplicated key) you usually want to commit *up to that
point* and not loose everything. does anybody know how to do that?
postgres seems just to ignore everything from the start until the commit
if an error occurs.
(Continue reading)

Permalink | Reply | 8 comments |

Gmane