Re: [sqlalchemy] Re: Objects are wrongly getting removed/expunged from session
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.
In my development, if a web request has an exception, that web request is over,
so the use case here is a little confusing to me to start with, and I don't
really understand why you need to manually flush or not since I don't have a
clear illustration of the issue.
On Jan 15, 2011, at 9:27 AM, Tvrtko wrote:
I've drilled down all the way up to `mapper._save_obj()`. I examined
the `state.dict` for `qitem`.
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, ...}
The `campaign` property is *relation* to `Campaign` entity. Campaign
is previously flushed and has id. But, for some reason the
`campaign_id` is missing inside `qitem` state event though the
`campaign` is present.
I can probably work around by saying:
qitem.campaign_id = campaign.id
but then I must rely on campaign being flushed which might not allways
be the case. Yes, I can flush it manually, but I like to depend on
relations functioning properly.
P.S. I am not restarting or changing application in any way, just
refreshing a web page, which sometime fails and sometime succeeds.
--
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.
Re: [sqlalchemy] Re: Objects are wrongly getting removed/expunged from session
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.
Re: [sqlalchemy] Re: Objects are wrongly getting removed/expunged from session
On Jan 15, 2011, at 11:53 AM, Tvrtko 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.
not suggesting you made a mistake. suggesting that some artifact of your
relationship setup may be causing the UOW to make the wrong decision. the
setup below seems very simple so it remains a mystery what would be causing the
issue.
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.
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.
Re: [sqlalchemy] Re: Objects are wrongly getting removed/expunged from session
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.
