Re: Must COMMIT after SELECT (was: Very weird behavior in MySQLdb "execute")

2008-02-07 Thread Paul Boddie
On 7 Feb, 08:52, Frank Aune <[EMAIL PROTECTED]> wrote: > On Wednesday 06 February 2008 16:16:45 Paul Boddie wrote: > > > Really, the rule is this: always (where the circumstances described > > above apply) make sure that you terminate a transaction before > > attempting to read committed, updated d

Re: Must COMMIT after SELECT (was: Very weird behavior in MySQLdb "execute")

2008-02-06 Thread Frank Aune
On Wednesday 06 February 2008 16:16:45 Paul Boddie wrote: > Really, the rule is this: always (where the circumstances described > above apply) make sure that you terminate a transaction before > attempting to read committed, updated data. How exactly do you terminate a transaction then?Do you term

Re: Must COMMIT after SELECT (was: Very weird behavior in MySQLdb "execute")

2008-02-06 Thread Paul Boddie
On 6 Feb, 16:04, Frank Aune <[EMAIL PROTECTED]> wrote: > > Whenever I did a SELECT() on the first connection, the cursor would > stop "seeing" new entries commited in the log table by the other connection. > I always assumed you needed COMMIT() after adding new content to the > database, not after

Re: Must COMMIT after SELECT (was: Very weird behavior in MySQLdb "execute")

2008-02-06 Thread Frank Aune
On Tuesday 05 February 2008 18:58:49 John Nagle wrote: > So you really do have to COMMIT after a SELECT, if you are reusing > the database connection. CGI programs usually don't have this issue, > because their connections don't live long, but long-running FCGI (and maybe > Twisted) programs d

Re: Very weird behavior in MySQLdb "execute"

2008-02-05 Thread John Nagle
Paul Boddie wrote: > On 4 Feb, 20:30, John Nagle <[EMAIL PROTECTED]> wrote: >>This has me completely mystified. Some SELECT operations performed >> through >> MySQLdb produce different results than with the MySQL graphical client. >> This failed on a Linux server running Python 2.5, and I can

Must COMMIT after SELECT (was: Very weird behavior in MySQLdb "execute")

2008-02-05 Thread John Nagle
Steve Holden wrote: > John Nagle wrote: >> Carsten Haese wrote: >>> On Mon, 2008-02-04 at 11:30 -0800, John Nagle wrote: Restarting the MySQL instance changes the database. The entry "google.com" disappears, and is replaced by "www.google.com". This must indicate a hanging >

Re: Very weird behavior in MySQLdb "execute"

2008-02-04 Thread Gabriel Genellina
On 5 feb, 01:42, Steve Holden <[EMAIL PROTECTED]> wrote: > John Nagle wrote: > > Carsten Haese wrote: > >> On Mon, 2008-02-04 at 11:30 -0800, John Nagle wrote: > >>> Restarting the MySQL instance changes the database.  The entry > >>> "google.com" > >>> disappears, and is replaced by "www.google.c

Re: Very weird behavior in MySQLdb "execute"

2008-02-04 Thread Steve Holden
John Nagle wrote: > Carsten Haese wrote: >> On Mon, 2008-02-04 at 11:30 -0800, John Nagle wrote: >>> Restarting the MySQL instance changes the database. The entry "google.com" >>> disappears, and is replaced by "www.google.com". This must indicate a >>> hanging >>> transaction that wasn't commit

Re: Very weird behavior in MySQLdb "execute"

2008-02-04 Thread John Nagle
Carsten Haese wrote: > On Mon, 2008-02-04 at 11:30 -0800, John Nagle wrote: >> Restarting the MySQL instance changes the database. The entry "google.com" >> disappears, and is replaced by "www.google.com". This must indicate a >> hanging >> transaction that wasn't committed. >> >> But that trans

Re: Very weird behavior in MySQLdb "execute"

2008-02-04 Thread Carsten Haese
On Mon, 2008-02-04 at 11:30 -0800, John Nagle wrote: > Restarting the MySQL instance changes the database. The entry "google.com" > disappears, and is replaced by "www.google.com". This must indicate a hanging > transaction that wasn't committed. > > But that transaction didn't come from the Pyt

Very weird behavior in MySQLdb "execute"

2008-02-04 Thread John Nagle
This has me completely mystified. Some SELECT operations performed through MySQLdb produce different results than with the MySQL graphical client. This failed on a Linux server running Python 2.5, and I can reproduce it on a Windows client running Python 2.4. Both are running MySQL 2.5. The