On Jan 17, 2013, at 10:27 AM, Derek Litz wrote: > with mysql_session() as s: > new_user = User(first_name=u'Derek') > s.add(new_user) > s.commit() > add_last_name(new_user.id) > # NOTE this makes sense, the object was never updated here > assert not new_user.last_name == u'Litz'
> # NOTE Why doesn't user receive the updated information? > user = s.query(User).filter(User.id == new_user.id).one() because you made the change to "User" in a different transaction (as a result of using a different Session). This transaction still continues and is considered to be "isolated" - SQLAlchemy doesn't invalidate the data until the transaction ends. If you say, s.expire(user), then you'll get the new value within the transaction, *assuming* the transaction isolation here is not enforcing repeatable reads. If MySQL is enforcing repeatable reads, you'll see the same data for user.last_name for each SELECT regardless of a change in another transaction. all about transaction isolation: http://dev.mysql.com/doc/refman/5.0/en/innodb-transaction-model.html > assert not user.last_name == u'Litz' > # NOTE Despite commit being the last thing I did for this session > # this fixes the problem. Why didn't it before? > s.commit() # or s.rollback() or s.close() the transaction here ends, ending any "repeatable read" state set up by that transaction (this would be via MySQL), and additionally the SQLAlchemy Session expires all the data. The next access starts a new transaction that gets the latest data. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
