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. -- pkm ~ http://paulmcnett.com _______________________________________________ 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]
