Uwe Grauer wrote: > Paul McNett wrote: >> Uwe Grauer wrote: >>> Would someone please answer the questions about the meaning >>> of autocommit? >>> See: http://svn.dabodev.com/trac/dabo/wiki/TransactionHandlingIdeas >>> This is a outstanding issue for a long time now. >> The doc says: >> >> """ >> AutoCommit >> >> Do we need explicit begin/commit/rollback commands for transactions? (bool) >> """ >> >> I believe that the original intent of AutoCommit was a flag to let >> methods in dCursorMixin know whether dCursorMixin has to explicitly >> commit transactions for a given backend or not. >> >> If that is true, I don't believe AutoCommit should have ever been >> exposed to the application developer, as it is an internal >> implementation detail. >> >> However, I also believe you can set AutoCommit for some backends, which >> will change the behavior of the backend. Some backends autocommit by >> default, most not, and some if not all allow the user to change the >> behavior. >> >> But looking at the code, it also looks like setting AutoCommit can >> silently fail for some backends, so we should raise an exception there I >> think. >> >> If nothing else, we certainly need to rewrite the docstring to state >> more explicitly what the property does, and how the initial setting of >> the property is derived. >> >> Ed, what do you think? >> > > Well, there is more than one interpretation of this. > If you look at it from a standpoint of a developer who doesn't > know much about transactions, then it's true that it is just a > implementation detail. But if you as a developer want to use ACID > in your database, the question is much more than this.
Let's back up a bit and remember that ACID compliance is a database-level concept, not an application-level concept. Either your database is ACID-compliant, or it isn't. No wrapper around that database, such as kinterbasdb or dabo can change whether or not the database is ACID compliant. What I think your objection boils down to is not enough control, from your application code, as to when the transactions BEGIN, COMMIT, and ROLLBACK. So you aren't able to get atomicity on all the database actions that you'd like (in the classic bank debit example, one account is getting debited and that transaction committed, instead of having both accounts credited/debited and then committing that transaction). Am I close? > There are the following cases: > 1. your database doesn't support transactions. I believe every database we currently support supports transactions. Indeed, I believe every database we currently support is ACID compliant. However, that may or may not be the case in the future, when/if we start supporting VFP or JET databases, and the like. > 2. your database supports autocommit and supports transactions. > 3. your database only supports transactions. > 4. your database doesn't have autocommit but you have to do a commit > in order to mimic a autocommit in the framework. How does 4 differ from 3? > Currently i can't use ACID features in firebird. > That's why it is something i want to get working for a long time now. Is this because the framework is saving your data automatically at inappropriate times, or something else? >>From the "help" i got by asking questions on this i have assumed that > the dabo users don't know much about transactions or that until now > nobody really thought about it. I think we've spent a lot of time trying to help you, but none of us have a lot of time to get to the bottom of the problems you've had, as they seem to be firebird-specific and we don't seem to be having problems with transactions in MySQL, SQLite, and PostgreSQL. > If this is not the case we should try to work out a better way to handle > those issues. > where the docs should be improved. I agree, and would welcome better docs and ideas on how to better handle transactions, or at least to test how they are currently working. But as I said above, I am not having any problems with transactions, in my SQLite app at least. I have bizobjs about 5 levels deep, with new/deleted/edited records in any or all levels, and multiple bizobjs at each level, and when I save the parent bizobj all the resulting SQL ends up in a single transaction. If a db exception occurs, everything is rolled back for me. So, it seems to be working but admittedly I'd love to see a test suite making sure that it works correctly in all conceivable cases. -- 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]
