rollback always expires everything in the session. As changes would have occurred within the flush process, a rollback implies those changes are lost, but also it normally indicates that the transaction is over, and between the rollback() and the next SQL statement which starts a new transaction, the state of anything may have changed relative to the database.
I can see that the case of rollback() to nested is a special case where we could expire only those objects known to have any dirty state, though I'm not 100% sure at the moment if there aren't some edge cases where an otherwise non-dirty object might be affected, but yeah I'm not really thinking of any. http://www.sqlalchemy.org/trac/ticket/2452 is added but this is for 0.8 which is already filling up with lots of new changes so it may be awhile before this is available. There's a small patch there you can try, if it works feel free to add some encouraging comments to the ticket.
In my application whenever I issue a rollback on 'sub-transaction' I
see (using logging.debug) that my main list is being reloaded from the
database.
In other words I do things like this:
- get application wide db session
- load the list of all the drinks
- begin_nested
- create/edit e.g. purchase item of one drink
- commit
- begin_nested
- create/edit another purchase item of the same drink as above
- rollback
- commit (to finally commit first purchase)
At this point all the drinks with all the relations etc are reloaded
from the database.
I tried with expire_on_commit but it doesn't seem to affect rollback.
Is there way to suppress the reloading of all the items and only load
the one affected by the changes by using expire(instance) or
refresh(instance)?
Werner