* Is there a way besides session.commit() to free the savepoint
resource?  Is there a way to provide the savepoint name, so I can use
the same name over?  Lastly, if you aren't the expert, where would you
point me, zope group or TG group?
you could issue the SAVEPOINT instructions manually if you don't like SQLA's 
abstraction of it, although then you don't get the Session's object management 
behavior around those savepoints (though it can be approximated).

Yeah, I've considered it.
I don't really understand what you're trying to achieve, such that SQLA is 
"forcing" you to create thousands of savepoints when you only need one.     Is 
the pattern that you want to keep re-issuing a savepoint repeatedly using the same name ? 
  Does that have some different usage of resources versus issuing/closing distinct 
savepoints with different names ?
I'm fine with how SQLA is designed, it isn't really a SQLA issue, I was just appealing to you to see if you could think of a workaround I believe the problem is in the framework tools we are using, whether it is Zope or TG. (I've posted to zope group now to see if they intended to support savepoints and how, etc.). Since that framework won't allow me to issue the command session.commit(), I cannot release the savepoints until the zope transaction commits, and by then I'm getting a python max recursion problem because there are so many outstanding savepoints for it to release.

So where I thought you could help is if there is another (even non-public) way to release the savepoint without calling session.commit()?

Ultimately I understand now that this is not a SQLA issue.

Thanks

--
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to