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.