Paul McNett wrote: > Uwe Grauer wrote: >> Ed Leafe wrote: >>> If I were using MySQL for the app, though, I should set AutoCommit >>> to True, but in practice it really doesn't matter, since the flush() >>> method is implemented for each backend, and for MySQL it does nothing >>> anyway. >>> >> Wrong. >> In MySQL it depends on the backend storage system which is used. >> When you are using ISAM tables, there is no transaction handling. >> In this case it doesn't matter if AutoCommit is True or False. >> If you are using InnoDb as the backend, MySQL supports transactions, >> so the setting depends on what you want to use (transactions or no >> transactions). > > I get the feeling that you and Ed are out of phase with each other and > responding to slightly different things. > > Anyway, the ISAM/InnoDB divide is probably what prompted us to expose > AutoCommit in the first place: we didn't want to just assume that all > MySQL databases wanted AutoCommit set to True. For ISAM, it wouldn't > matter, because there aren't transactions anyway so the 'commit' would > happen during the execute(). But for Inno, you'd set AutoCommit to False > to tell Dabo it needs to do the commit() call when appropriate (when you > do biz.save()). Or, you'd leave it at True to tell Dabo that you've got > got MySQL set to do auto transactions, so all Dabo needs to do is run > the update(), insert(), or delete() and the backend would automatically > do the commit(). > > Again, I believe that AutoCommit is named almost backwards, and that we > need a new ExplicitTransactions property. >
For reference, see: http://dev.mysql.com/doc/refman/5.1/en/innodb-and-autocommit.html _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/dabo-dev/[EMAIL PROTECTED]
