On Wednesday 25 March 2009 10:05:52 Raphael Slinckx wrote:
> From what i could understand of the code, it's simply impossible for
> the extension to trigger a commit when working outside the DBSession
> since it's a session plugin.
I don't understand this. Who's working outside a session?
> Here's what I did to still have commit work when using raw sql
> statements:
>
> import transaction
> from zope.sqlalchemy.datamanager import join_transaction,
> STATUS_CHANGED
> join_transaction(DBSession(), STATUS_CHANGED)
> DBSession.execute(table.insert(), [{'foo': bar}])
> transaction.commit()
>
> And then SA issues a COMMIT, and does so inconditionaly since i forced
> the status to changed.
> Clearly the fact that transaction.commit() won't work after a
> DBSession.execute() needs to be documented somewhere
I don't have deep insights into the SA and zope.transaction code (ZT), but
it's pretty obvious that
- ZT must rely on SA to communicate a dirty session
- already does so for modified mapped objects
- doesn't for issued sql
- SA OTOH *does* know if a transaction is dirty, even without any mapped
objects being touched.
So there is some missing link there. It might well be that there is no obvious
way for an extension to figure that out - but somehow that must be possible, at
least through poking into some internals of the session. As last resort, I
guess one could think about making your above recipe part of every request -
which causes needless commits of course, but I'd rather have these than data
loss.
Diez
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
