From: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
---|---|
To: | Marko Kreen <markokr(at)gmail(dot)com> |
Cc: | psycopg(at)postgresql(dot)org |
Subject: | Re: Rollback on close [Was: Fwd: [DB-SIG] conn.close() idempotence] |
Date: | 2011-10-19 18:34:11 |
Message-ID: | CA+mi_8YA4Qmdgz99DaGDoypxJ+rzSvE-z020P3t80u1ti9Q3TQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
On Wed, Oct 19, 2011 at 6:50 PM, Marko Kreen <markokr(at)gmail(dot)com> wrote:
> Let's clarify that further - DB-API *MUST* say that .close()
> [and also .__del__()] will rollback. Eg - imagine
> driver accessing .dbf / .csv files directly.
>
> But there is no good reason to require communication
> with backend if the backend will rollback anyway
> on connection close.
Yes, this is our current position. Changing from it could only improve
the interaction between "sloppy code" and middleware, and as you have
pointed out this would make edge case more troublesome.
Thank you for the discussion, I wanted to hear the opinion of somebody
on the other side of the socket :)
-- Daniele
From | Date | Subject | |
---|---|---|---|
Next Message | Frank Kauff | 2011-10-19 19:35:45 | Re: Error: no Python Codec for client encoding |
Previous Message | Marko Kreen | 2011-10-19 17:50:15 | Re: Rollback on close [Was: Fwd: [DB-SIG] conn.close() idempotence] |