On May 31, 2010, at 10:28 AM, Kent Bower wrote:
>> that's how the engine-level API works - you get at a Transaction object that
>> you can roll back anywhere in the chain (its up to you to know that the
>> other Transaction objects in the middle are no longer valid).In the ORM
>> we wanted
On 5/31/2010 9:55 AM, Michael Bayer wrote:
On May 31, 2010, at 8:24 AM, Kent Bower wrote:
Although sqla doesn't allow the user to specify the savepoint name, the same
could be accomplished given if support for the following were implemented:
Let me ask:
sp_a=begin_nested()
...
...
sp_b
On May 31, 2010, at 8:24 AM, Kent Bower wrote:
> Although sqla doesn't allow the user to specify the savepoint name, the same
> could be accomplished given if support for the following were implemented:
>
> Let me ask:
>
> sp_a=begin_nested()
> ...
> ...
> sp_b=begin_nested()
> ...
> ...
> sp_
On 5/30/2010 1:24 PM, Michael Bayer wrote:
On May 28, 2010, at 1:46 PM, Kent Bower wrote:
On 5/28/2010 10:08 AM, Michael Bayer wrote:
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
On May 28, 2010, at 1:46 PM, Kent Bower wrote:
> On 5/28/2010 10:08 AM, Michael Bayer wrote:
>> 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 dif
On 5/28/2010 10:08 AM, Michael Bayer wrote:
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 ?
As an aside, since oracle apparently has n
On May 28, 2010, at 1:24 PM, Kent wrote:
>
>
> On May 27, 6:39 pm, Michael Bayer wrote:
>
>> commit() releases the savepoint, if thats whats going on contextually. It
>> doesnt actually commit the outer transaction if you've last called
>> begin_nested().
>>
>
>
> In a SessionExtension
From a quick reading of the 'transaction' package source, it looks like
you should be able to create savepoints and roll them back something
like this:
savepoint = transaction.savepoint()
try:
# ...
except:
savepoint.rollback()
raise
Thanks for the interest in helping. I had
Kent wrote:
[SNIP]
> 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 se
* 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 manuall
On May 28, 2010, at 8:47 AM, Kent wrote:
> Say I have this:
>
> session().begin_nested()
> try:
>session.add(obj)
>session.flush()
>session.commit()
> except:
>session.rollback()
> ...
> transaction.commit()
>
> 2 questions:
>
> * I assume that the session.rollback() undoes the
11 matches
Mail list logo
