How to use SQLite (sqlite3) more efficiently


R Johnson

Thank you all for your replies and suggestions.

To Chris's "two small points":
I saw that using the mailing list was recommended to several other
people who posted here using Google Groups, so I thought it might be
recommended to me as well sometime :). I'll try to use it from now on.
My code was tested on Python 2.7.6 on Windows 8.1 (and I just installed
Python 2.7.7 yesterday).
There's a general principle in Python APIs that a "mode switch"
parameter isn't a good thing. Even more strongly, I would be very
surprised if attempting to set a blank description deleted the row
instead of setting the description to blank. My recommendation: Split
this into two functions, set_description and delete_language. In
delete_language, just unconditionally delete, don't bother checking
for the row's presence first.

I agree for the case of the sample code I showed here (which was really
just a scaled-down version of some of the functions in my program). But
in my actual program, I am using SQLite to load and save information
from a wxPython GUI, where it's more practical to call a single save
function. Below is the actual function (that's part of a class in my

def save_text(self):
if not self.editor.IsModified():
if not self.editor.IsEmpty():
stream = cStringIO.StringIO()
self.conn.execute("REPLACE INTO notes VALUES(?,?)",
(self.db_key, stream.getvalue()))
self.conn.execute("DELETE FROM notes WHERE topic=?",

(Even if you're not familiar with wxPython, it should be fairly easy to
figure out what the code is doing. It's just saving some XML from a rich
text editor to a StringIO object, and then to an SQLite database.)
Hey, that's not fair! Assembly language makes some hard things really
easy, like segfaulting your process. Credit where it's due! :)

OK, I'll admit that I don't know Assembly :). How about the paradox
"Making Easy Things Hard & Hard Things Easy"? Although that might make
my description of C++ too unfair; suggestions for improvements to my
language descriptions are welcome :).
While /maybe/ not required for a SELECT operation, I'd put a
conn.commit() somewhere in there before the return(s). The standard for
Python DB-API interfaces is that auto-commit is turned off -- meaning the
SELECT has started a database transaction.

I don't exactly understand why conn.commit() should be called there. I
thought it's only necessary to call it when the database has been
changed, which a SELECT call doesn't do. Am I misunderstanding something
This isn't really doing anything useful. You aren't opening a new
connection object, so there isn't really anything to close on block

I removed it from my code, though, because it doesn't really seem necessary.

I've attached some new sample code in which I've attempted to correct
various things that you mentioned. The links Peter pointed to were also
helpful to show me some improvements I could make to my code. I'd be
happy to hear any suggestions that anyone may have to improve the code

-- Timothy

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Latest member

Latest Threads