Ed Leafe wrote:
> dabo Commit
> Revision 3314
> Date: 2007-08-19 12:07:48 -0700 (Sun, 19 Aug 2007)
> Author: Ed
> Trac: http://svn.dabodev.com/trac/dabo/changeset/3314
> 
> Changed:
> U   trunk/dabo/biz/dAutoBizobj.py
> U   trunk/dabo/biz/dBizobj.py
> U   trunk/dabo/biz/test/test_dBizobj.py
> U   trunk/dabo/dApp.py
> U   trunk/dabo/dPref.py
> U   trunk/dabo/db/dBackend.py
> U   trunk/dabo/db/dCursorMixin.py
> U   trunk/dabo/db/dbFirebird.py
> U   trunk/dabo/db/dbMySQL.py
> U   trunk/dabo/db/dbPostgreSQL.py
> U   trunk/dabo/db/dbSQLite.py
> U   trunk/dabo/db/test/test_dCursorMixin.py
> 
> Log:
> Major re-write to the way that transactions are handled in the bizobj and 
> database layers.
> 
> These changes are designed to work within the entire framework; i.e., 
> applications, forms, bizobjs and cursors. If you use any single piece of the 
> framework separately, such as a raw cursor, you will have to manage 
> transactions yourself.
> 
> Transactions now happen happen by default when calling biz.save()/saveAll() 
> and biz.delete()/deleteAll(). If for some reason you do not want 
> transactions, you must call them with the parameter startTransaction=False.
> 
> Only one bizobj will begin and commit/rollback. All others do not touch 
> transactions, as they are within the current transaction. Upon a save or 
> delete method being called, the bizobj will request the transaction 'token' 
> from the app. If no other bizobj has started a transaction, it will have True 
> returned from the request, and the bizobj will handle the transaction. If 
> there are related bizobjs who in turn have their save/delete methods called, 
> their requests for the token will be denied, so they will not do anything 
> regarding transactions. When the process is completed in the initial method 
> that requested the token, either a commit or rollback will be called, and the 
> token released.
> 
> This design eliminates the problem with nested and chained bizobjs starting 
> and/or ending multiple transactions. Only the original bizobj in the process 
> can manage transactions, and only from the method that was originally called.
> 
> The 'AutoCommit' property has been removed. Defaulting transactions to being 
> used by default will handle the call to commit(). Again, if you deal with 
> cursors directly (as is done in dPref.py), the commit calls must also be 
> handled manually.

This is good news. Many thanks!
I'm glad i didn't find the time in the weekend to change the
AutoCommit handling for Firebird.

Uwe


_______________________________________________
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]

Reply via email to