On Jan 15, 2011, at 8:37 PM, Tvrtko wrote:

> 
> 
> On Jan 15, 5:53 pm, Tvrtko <qvx3...@gmail.com> wrote:
>> This is my first such case in 5-6 years of using the SA. Usually the
>> problem was with my code. This could also be the case now, but it
>> escapes me where I made a mistake.
>> 
>> Thank you for your time. I will consider this closed for now and move
>> on using a workaround of explicitly populating campaign_id. I guess I
>> will try 0.6 or even 0.7 in the next few months.
> 
> I couldn't resist.
> I'm pleased to say that it works just fine in SA 0.6

I rewrote the UOW entirely from scratch in 0.6.   The last remaining 
incompatibilities were gone by 0.6.4 or so.    Wait til you see what it does in 
0.7.



> 
>> 
>> Thanks,
>> Tvrtko
>> 
>> P.S. for the curious, my relations go like this:
>> 
>> from elixir import Entity, Field, ...
>> 
>> class Campaign(Entity):
>>     id = Field(Integer, Sequence('cc_campaign_seq'),
>> colname='campaign_id', primary_key=True)
>>     qitems = OneToMany('QItem')
>> 
>> class QItem(Entity):
>>     id = Field(Integer, Sequence('cc_qitem_seq'), colname='qitem_id',
>> primary_key=True)
>>     campaign = ManyToOne('Campaign', colname='campaign_id',
>> required=True)
>> 
>> On Jan 15, 5:32 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> 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.
> 

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

Reply via email to