On 2017-05-30, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote: > On Tue, 30 May 2017 15:12:55 -0000 (UTC), Jon Ribbens ><jon+use...@unequivocal.eu> declaimed the following: >>I can't make head nor tail of what they are trying to say there. >>Mind you, it doesn't help that the DB-API concept of cursors seems >>to bear almost no resemblance to the SQL concept of cursors. > > The main concept is that (set autocommit to False, for those DB > adapters that have autocommit) a transaction is implicitly begun on the > first SQL statement that accesses the data (though I think I've read that > SQLite doesn't start a transaction until one submits an SQL statement that > modifies data). > > And this behavior apparently matches version 1 of the SQL "standard". > Version 2 added explicit "begin" -- I suspect Python DB-API adapters to a > ver2 database are suppose to issue the "begin" whenever the adapter > believes there is no open transaction.
Indeed. As I say, I think perhaps the source of the confusion is that DB-API cursors make no sense at all, rather than the problem being transactions per se. It's almost as if DB-API was written by someone who had never seen a database. 'execute' being a method of the cursor rather than the connection is a logical impossibility - cursors are something that are returned by SQL execution, not the other way around. If DB-API had Connection.execute, then Connection.commit wouldn't be strange. Cursor.execute is bizarre, and it being paired with Connection.commit is just icing on the bizarre cake. -- https://mail.python.org/mailman/listinfo/python-list
