Flutterby™! : design question 2004-10-07 00:24:09.989698+00

design question

2004-10-07 00:24:09.989698+00 by Dan Lyke 5 comments

Okay, design question: I've got a class which abstracts out most of the database operations, and because I'm concerned about speed and multi-userness, I'm trying to commit() only when necessary. I'm torn between remembering to commit() at the high levels (and what happens when things are called in different configurations?) versus trying to have my classes assume a certain granularity of operation. Anyone run into good rants on the topic?

#Comment Re: design question made: 2004-10-07 05:03:16.457937+00 by: dws

If you can sketch out use cases or usage scenarious that include UI operations, they may suggest natural high-level commit points.

First, are you sure this isn't a premature optimization? Getting clever with commits seems to be asking for data corruption to me.

Anyway, here's a trick I've used before: Create two classes of transactions. 'Basic' transactions go at the lowest level of the code, where maybe they'll get called too often, but there's no chance of corruption. 'Grouping' transactions can hold other transactions, and only the outermost group actually causes a commit. If you start having problems in the code, you turn off the grouping transactions.

It also goes the other way, committing too early can leave dangling unreferenced objects, although many years pre modern day overpowered machines means I'm pretty conscious of inserting in an order so that the database always makes sense, and cleaning stuff up manually, not depending on rollback.

Since the Python

bindings don't seem to have a way to toggle autocommit, I like your idea of putting that into the database abstraction class, and having several layers of commit severity.

Calling begin() on the connection implicitly toggle autocommit off, assuming you're using something my MySQLdb.