On 4/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]
> wrote:
Each method call is a transaction unless you say otherwise
I'm sorry but that sounds so php, python/tg is not php don't try to use it like that.
if you must I believe what you need is a class variable. but it seems more like a need to reestructure the code so each method is one web call (or calls methods that are not exposed to factor the work.
since the backend is change the "lock" is lost so SQLObject can not be sure that is the most recent copy.
that doesn't makes sence.
Hi,
A suggestion for the documentation of 0.9.
It would be great to have a section that goes over some of the
practical issues and gotchas arising from database transactions and how
they are managed by default
in TG 0.9
Each method call is a transaction unless you say otherwise
For example, I had a pattern where I try to pass objects from one web
app "page" (exposed method) to the next page (i.e. to the page that I
redirect to) by having the objects be the value of a session key.
I'm sorry but that sounds so php, python/tg is not php don't try to use it like that.
if you must I believe what you need is a class variable. but it seems more like a need to reestructure the code so each method is one web call (or calls methods that are not exposed to factor the work.
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?
since the backend is change the "lock" is lost so SQLObject can not be sure that is the most recent copy.
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,
that doesn't makes sence.
then re-get the object from the database within the
next page's code. Is this a correct observation, a necessary pattern?
Any best-practices patterns or advice to go along with the implicit
transactions design would be very handy.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
