the zope transaction integration i did, basically implements a
transaction manager for sqlalchemy.
http://svn.objectrealms.net/svn/public/alchemist/trunk/engine.py
http://svn.objectrealms.net/svn/public/alchemist/trunk/manager.py
as an example of usage
import transaction
from engine import get_engine
# the get_engine accessor, automatically registers the engine
# if its not already with current transaction
engine1 = get_engine('postgres://database=alchemy')
engine2 = get_engine('oracle://database=tiger')
# execute some queries against both engines
# do some orm stuff against both engines
# play with the current transaction object
txn = transaction.get()
# both engines commit or succeed together, the objectstore also gets
# committed.
if good_stuff:
transaction.commit() # alternatively txn.commit()
else:
transaction.abort() # alternatively tx.abort()
the approach relies on the thread local connection pool behavior, and is
structured as a mixin that null implements the default sa transaction
behavior and delegates to the zope transaction manager for driving. the
get_engine accessor automatically adds the mixin behavior to the default
engines. its suffered some bit rot, due to this being a topic of change
for sa. behaviorally, due to the null implementing of sa txn behavior it
relies on a single session in the session stack.
i definitely think a transaction manager abstraction would be nice. i'm
not a big fan of the session juggling thats currently there, i think
deferring to a transaction manager and let people plug policy there as
nesc, is a much cleaner approach. as long the capability for independent
connections with independent sessions is there (like
engine.unique_connection) then the oddball use cases are covered. my
primary concern and use cases for sa are based on being able to use it
with zope and hoping that can be preserved regardless of whats done.
i've touched on it before, but the zope transaction api is pretty nice,
it optionally supports savepoints (if all participating data managers
support it), does a two phase commit between data managers (rdbms that
don't support tpc, can still work here, though with a greater potential
for tpc failure since their faking it ), and allows for observers and
metadata. its commonly used to coordinate transactions across the zodb,
fs, rdbmses, and its easy to use outside of zope, it's basically two
packages of dependencies (transaction, and zope.interface).
incidentally i was interested in contributing this integration as an SA
extension, and wondering what that process is?
cheers,
kapil
Michael Bayer wrote:
On Apr 6, 2006, at 3:01 AM, Qvx wrote:
I can work around all those issues (allready have) by explicitely
managing my transactions, but it would be nice if we could make it
work. Something like this:
# called from decorator
def run_with_transaction(func, *arg, **kw):
try:
# "begin" but don't necessary touch the database yet
sqlalchemy.something.implicitly_begin_all()
sqlalchemy.objectstore.clear()
retval = func(*args, **kw)
# now commit everything that was used in this thread
sqlalchemy.something.commit_all_used_dbs()
return retval
except:
sqlalchemy.something.rollback_all_used_dbs()
In this case I'm not sure haw would SA respond to
begin/commit/rollback inside decorated function. Ignore commits
because there was implicitly_begin_all() or allow me to explicitly
manage my affairs if i want.
I had in mind something like ,
# start new transaction
x = TransactionManager.Transaction()
then inside of engine.py, right at the point it uses the underlying
connection (this is very simplified):
def _execute(self, c, statement, parameters):
# join into the transaction already in progress
x = TransactionManager.current_transaction()
if x is not None and self not in x:
self.join_transaction(x)
c.execute(statement, parameters)
so that way, you wouldnt have to know what connections would be used,
each engine (or ConnecitonProxy, or something) would join in as they
were used.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
