Thanks very much for the reply. So if I understand correctly, with this sequence of operations, transaction isolation will prevent seeing the new data...
Fetch data by doing a query on the ORM class. Change some of the same data directly in the database with cx_Oracle, and commit the change. (The changed data is in a child table.) Expire the ORM class. (cascade=...refresh-expire..) Reference the ORM class again -- data still old. Do I have that right? Does the session have just one of each object, regardless of parent/child relations? I'll check the sql logs and I'll try to make an example. At least I now understand what part to make an example of! On Dec 10, 8:35 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Dec 10, 2008, at 6:17 PM, MHC wrote: > > > > > So the problem is, I do the query and show the object to the user, say > > thing1. Then using cx_Oracle, I change thing1.thing2.someAttribute in > > the database. Then I expire thing1. But when I show the user thing1 > > again, thing1.thing2.someAttribute contains the old value. > > > Shouldn't the 'refresh-expire' argument cause > > thing1.thing2.someAttribute to be re-fetched automatically? > > you can ensure that the fetch operation is occuring as expected by > watching your SQL logs. If you have not commited or rolled back the > current transaction, transaction isolation will prevent you from > seeing data from concurrent transactions. If you use the Session's > default behavior in 0.5 the contents of the session are fully expired > after a commit() or rollback(), and I'd recommend that approach. you > can also call expire_all() to expire everything. The Session can > handle any number of transactions and can be kept long running. > > > Although explicitly expiring thing1 doesn't seem to help, explicitly > > refreshing it seems to fix the problem. Aren't those essentially the > > same thing? > > they do exactly the same thing so if you can create a short example > illustrating how you are seeing a behavioral difference that would be > appreciated. we have well over two dozen tests for various expiry- > based behaviors. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
