paid_120_count = session.query(Capital_invest.member_id,
func.count().label("count")).\
join(Product,
Capital_invest.prod_id==Product.prodid).\
filter(Product.price*payback_pc-
Capital_invest.capital_payback<=0).\
group_by(Capital_invest.member_id).subquery()
buy_product_count = session.query(Capital_invest.member_id,
func.count().label("count")).\
group_by(Capital_invest.member_id).subquery()
x_members = session.query(Distributor).\
join(paid_120_count,
paid_120_count.c.member_id==Distributor.id).\
join(buy_product_count,
buy_product_count.c.member_id==Distributor.id).\
filter(paid_120_count.c.count==buy_product_count.c.count).\
filter(Distributor.quali_bonus==True)
So the distributor is the center table joins two queries. The Query
returns data without problem. But i can't update the result data
subsequently, for example
for member in x_members:
member.name ="xxxxx"
The sqlalchemy just simply do nothing. I have to do this:
for member in x_members:
member.name ="xxxxx"
dist = session.query(Distributor).get(member.id)
dist.name = "xxxxx"
Is there something I missed for getting this issue?
Thanks for someone pointing out the clue.
did you close out the Session before you iterated through x_members ? This test will ensure you're doing things correctly:
for member in x_members:
dist = session.query(Distributor).get(member.id)
assert dist is member
the identity map will ensure they are the same instance, *if* you are operating on x_members as present in the Session. If the Session got closed before you iterated, you'd need to not do that.
DBSession = scoped_session(sessionmaker( extension=ZopeTransactionExtension()))
It's likely you're starting with a new Session when begin() is called, but this depends on the workings of ZopeTransactionExtension and I'd ask on their list about it.
You shouldn't have any calls to begin/abort/try/except when using Pyramid though, all of that should be happening behind the scenes. A framework isn't worth much if you need to be hand-coding defensive transaction blocks in application code.
> And I was suspecting it is the reason of the complex joins in usage, because I have other code that doing things in the same way,
the structure of the Query/ SELECT statement that gets you back some data has no connection on how that data behaves later on. Your original case seems a simple case of the session being closed prematurely.