Flutterby™! : design question

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

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?

[ related topics: Software Engineering Databases ]

comments in ascending chronological order (reverse):

#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.

#Comment Re: made: 2004-10-07 05:39:03.799383+00 by: dexev

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.

#Comment Re: made: 2004-10-07 19:12:46.59784+00 by: Dan Lyke

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[Wiki] 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.

#Comment Re: made: 2004-10-08 04:02:02.049819+00 by: dws

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

#Comment Re: made: 2004-10-08 04:33:11.860781+00 by: dexev

for postgres, the query "set autocommit=off" should do it.