On Jan 9, 2011, at 4:26 PM, Romy wrote:

> Okay. In assembling a test case I've noticed the following behavior.
> When the mapped object is created before the begin(), the bug is
> reproducible. When it's created after the begin(), the rollback
> happens correctly and the 'bug' disappears. Specifically:
> 
>    invite_code = InviteCode.query.first()
>    elixir.session.begin()
>    invite_code.used = invite_code.used + 1
> 
> breaks, but the following works:
> 
>    elixir.session.begin()
>    invite_code = InviteCode.query.first()
>    invite_code.used = invite_code.used + 1
> 
> Is that normal, or is it a bug ? If it's normal, how do I best deal
> with needing to use the object before the transaction -- would I need
> to reissue the query ?

Still not seeing how that would make a difference if that's fully what's going 
on.  What is the value of "invite_code.used" after the assignment ?   Does 
loading "invite_code.used" change the result of the output ?  Can you test 
"assert invite_code in elixir.session" ?








> 
> Thanks.
> 
> On Jan 9, 8:10 am, Michael Bayer <mike...@zzzcomputing.com> wrote:
>> yeah there's not really enough detail here to produce an explanation, you'd 
>> need to narrow it down into a self-contained test case.
>> 
>> On Jan 9, 2011, at 1:45 AM, Romy wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> I believe it's both mapped and present in the session -- the log
>>> output seems to confirm it:
>> 
>>> [I 110108 22:40:30 base:1075] BEGIN
>>> [I 110108 22:40:30 base:1390] UPDATE invite_codes SET used=%s WHERE
>>> invite_codes.id = %s
>>> [I 110108 22:40:30 base:1391] (1L, 100L)
>>> [I 110108 22:40:30 base:1390] INSERT INTO users (username, email,
>>> password, verified, usertype_id, invite_code_id, created,
>>> invites_left) VALUES (%s, %s, %s, %s, %s, %s, %s, %s)
>>> [I 110108 22:40:30 base:1391] (u'blah', u...@b.com', '<snip>', False,
>>> 1L, 100L, datetime.datetime(2011, 1, 9, 6, 40, 30, 808683), 5)
>>> [I 110108 22:40:30 base:1086] ROLLBACK
>> 
>>> The update's part of the transaction above, but it doesn't get rolled
>>> back.. scratching my head here.
>> 
>>> On Jan 8, 8:20 am, Michael Bayer <mike...@zzzcomputing.com> wrote:
>>>> The "rollback" of attributes is actually an expiration of all mapped 
>>>> attributes.    So "used" would need to be a mapped column for its value to 
>>>> be "rolled back".   Other than that, "invite_code" would need to be 
>>>> present in "elixir.session" for that to work, if something is causing that 
>>>> not to be the case, that would also exclude it from the expiry.
>> 
>>>> On Jan 8, 2011, at 1:23 AM, Romy wrote:
>> 
>>>>> This may or may not be specific to SQLAlchemy (rather than elixir),
>>>>> but I figured I'd ask seeing as how this list is much more active. I'm
>>>>> experiencing only a partial rollback in the following code --
>>>>> invite_code gets incremented even when the exception is caught and
>>>>> session rolled back. When I switch the two lines after begin(), this
>>>>> goes away. I'm using autocommit=True, sqlalchemy 0.6.4.
>> 
>>>>> ---------------------------------------------------
>>>>> invite_code =
>>>>> InviteCode.query.filter_by(code=code).first()
>> 
>>>>> elixir.session.begin()
>>>>> user = User(...)
>>>>> invite_code.used = invite_code.used +
>>>>> 1
>> 
>>>>> try:
>> 
>>>>> elixir.session.commit()
>>>>> except
>>>>> IntegrityError:
>>>>>  # Thrown on duplicate email
>>>>> address
>> 
>>>>> elixir.session.rollback()
>> 
>>>>> return
>>>>> ---------------------------------------------------
>> 
>>>>> Cheers!
>> 
>>>>> --
>>>>> 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 
>>>>> athttp://groups.google.com/group/sqlalchemy?hl=en.
>> 
>>> --
>>> 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 
>>> athttp://groups.google.com/group/sqlalchemy?hl=en.
> 
> -- 
> 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.
> 

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