On Jan 15, 2011, at 11:10 AM, Tvrtko wrote:
>
>
> On Jan 15, 4:35 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
>> So, you have A->B, an exception occurs, you do the rollback, then you're
>> somehow trying to continue on within the web request ? The code examples
>> here are out of context snippets and I don't see any exception handling
>> happening so they don't really tell me much. When the flush fails, the
>> internal state is completely expired. Campaign, if pending when the
>> transaction started, now transient again, qitem is also transient.
>> Previous flushes within that transaction have no effect on this. Campaign
>> and qitem would retain their relationship to each other, campaign_id would
>> probably remain present, but if you were to re-add the two, it would be
>> overwritten on the next flush.
>
> You are right. I presented the issues in a confusing manner because I
> was not exactly sure what was happening in the first place.
>
> I am *not* continuing with request after exception. I was reraising
> exception after a debug print. Unfortunately that debug print has lead
> me in the wrong direction of thinking that objects were expunged
> before the flush. That is not the case.
>
> What actually happens is that save mechanism sometimes gets underlying
> ID from related object end sometimes it doesn't. Note that campaign
> has ID, and that campaign is associated with qitem and still,
> qitem.contact_id is not allways set during a save/flush.
>
> Debug print from inside `mapper._save_obj()`:
>
> Good case:
>
> qitem state dict = {'campaign': <Campaign 233, u'Test'>,
> 'campaign_id': 233, ...}
>
> And for the bad case:
>
> qitem state dict = {'campaign': <Campaign 234, u'Test'>,
> 'campaign_id': None, ...}
OK, then I need a full reproducing test case which shows how that result
occurs. Its not a known issue off the top of my head. Also, please note
that I am in no way suggesting you upgrade your application to 0.6, however, if
you test your development code with 0.6 and the problem goes away, that would
indicate something specific to 0.5 might be the cause. I would suggest that
it may be related to how your relationships are set up, such that a dependency
between QItem and Campaign is not correctly established, leading the ORM to
sometimes handle one or the other first.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@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.
