On 12/04/2006, at 2:55, [EMAIL PROTECTED] wrote: > However, I'm getting "this transaction has already gone through > ROLLBACK" errors when I try to access the attributes of the object in > the 2nd page's code. > I imagine this to be because the transaction in which the object was > created has been committed (or something) and the same object is no > longer valid inside the next transaction? I'm not sure what causes > this > problem but I've come to the conclusion that > I ought to pass object identifiers around for page to page rather than > object themselves, then re-get the object from the database within the > next page's code. Is this a correct observation, a necessary pattern?
Yep, this a correct observation. All requests are implicitly wrapped in a transaction to guarantee that all changes made in your DB during that request will be atomic. This isn't absolutely necessary, but "good practice". The reason for this is that the records those objects represent might be modified in a race-condition fashion (by a concurrent request) leading to inconsitent data messing your DB and hard to track bugs. It was decided long ago to make this default behavior. If you need to store SQLObject in session storage, you can wrap them in a proxy of some sort that does this automatically for you. ASPN has plenty of recipes for proxies which you can use for inspiration. Alberto --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears -~----------~----~----~----~------~----~------~--~---
