Re: Automatic rollback on error, duplicate key?
"Billy G. Allie" <[email protected]>
| Newsgroups | gmane.comp.python.db.pypgsql.user |
|---|---|
| Message-ID | <[email protected]> |
[email protected] wrote: > > Gerhard, thanks for responding so quickly! > > > No, that is indeed what's currently going on. I agree it's odd and I > > think it should be changed. The only question is: how exactly should the > > behaviour be? Hmm. Maybe I should look how psycopg implement it. > > I just received a note from a friend of mine: > > > You're not going to like the answer you get -- it's not a function of > > the Python driver, it's the database itself. Postgres treats a duplicate > > key in a unique index as an error so it rolls back the entire transaction > > > Very lame, I know -- I ran into this when I was setting up > > . . . > > . . . > > This is documented as a possible future enhancement: > > > > http://www.postgresql.org/idocs/index.php?wal.html > > Oops. I've done this a lot before, but I guess it was always with > Oracle, and not Postgres. It sounds like there's nothing pypgsql can > do to avoid it? > > -Bob This is indeed the case. In fact, special care was needed in PgSQL in order to try to get back to a sane state when PostgreSQL aborted the transaction. Here is the relevant code snippet: except OperationalError, msg: # Uh-oh. A fatal error occurred. This means the current trans- # action has been aborted. Try to recover to a sane state. if self.conn.inTransaction: _n = len(self.conn.notices) self.conn.conn.query('ROLLBACK WORK') if len(self.conn.notices) != _n: raise Warning, self.conn.notices.pop() self.conn.__dict__["inTransaction"] = 0 self.conn._Connection__closeCursors() raise OperationalError, msg -- ____ | Billy G. Allie | Domain....: [email protected] | /| | 7436 Hartwell | MSN.......: [email protected] |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 |
signature.asc
(application/pgp-signature, 2.3 KB)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii [email protected] wrote: > > Gerhard, thanks for responding so quickly! > > > No, that is indeed what's currently going on. I agree it's odd and I > > think it should be changed. The only question is: how exactly should the > > behaviour be? Hmm. Maybe I should look how psycopg implement it. > > I just received a note from a friend of mine: > > > You're not going to like the answer you get -- it's not a function of > > the Python driver, it's the database itself. Postgres treats a duplicate > > key in a unique index as an error so it rolls back the entire transaction > > > Very lame, I know -- I ran into this when I was setting up > > . . . > > . . . > > This is documented as a possible future enhancement: > > > > http://www.postgresql.org/idocs/index.php?wal.html > > Oops. I've done this a lot before, but I guess it was always with > Oracle, and not Postgres. It sounds like there's nothing pypgsql can > do to avoid it? > > -Bob This is indeed the case. In fact, special care was needed in PgSQL in order to try to get back to a sane state when PostgreSQL aborted the transaction. Here is the relevant code snippet: except OperationalError, msg: # Uh-oh. A fatal error occurred. This means the current trans- # action has been aborted. Try to recover to a sane state. if self.conn.inTransaction: _n = len(self.conn.notices) self.conn.conn.query('ROLLBACK WORK') if len(self.conn.notices) != _n: raise Warning, self.conn.notices.pop() self.conn.__dict__["inTransaction"] = 0 self.conn._Connection__closeCursors() raise OperationalError, msg - -- ____ | Billy G. Allie | Domain....: [email protected] | /| | 7436 Hartwell | MSN.......: [email protected] |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.2 (UnixWare) Comment: Exmh version 2.2 06/23/2000 iD8DBQE90I8/nmIkMXoVVdURAksDAJ4yn2ognZoKKlVtjRvk49mPJrr2CACg+8xk nQgQQjnQd37JqYBpRlN9TQs= =IGxX -----END PGP SIGNATURE-----