#1185: controller method trying to flush the database session(sqlalchemy) even
if
exception occours
------------------------+---------------------------------------------------
Reporter: sanjay | Owner: anonymous
Type: defect | Status: new
Priority: normal | Milestone:
Component: unassigned | Version: 1.0b1
Severity: normal | Resolution:
Keywords: |
------------------------+---------------------------------------------------
Comment (by alberto):
This is related to the auto-saving behavior of
[http://www.sqlalchemy.org/docs/plugins.myt#plugins_assignmapper
assign_mapper] and
[http://www.sqlalchemy.org/docs/plugins.myt#plugins_sessioncontext
sessioncontext].
Let me explain:
When you create an instance of a mapped class which is handled by
assignmapper it is automatically attached to the current session on
construction. So, even if an exception occurs afterwards (in assignName)
the object is already in the session.
The exception is raised, catched by errorhandling and execution branches
to index where it is displayed *and* the session finally flushed (as no
exceptions occur inside index).
There are 3 solutions possible (that I can think of ATM):
1. Clearing the session inside index() if an error or exception occurs so
when it's flushed nothing is saved.
2. Don't use activemapper and manually save "person" in the session if
assignName succeds.
3. re-raise tg_exceptions inside index() so the transaction is rolled-
back
1. is probably what you want, I believe. See attached files to see how to
implement it
There's room for improvent in TG in this regard I believe... Probably when
an exception is trapped by errorhandling a flag should be set in the
request to inform run_with_transaction (the wrapper that expose uses to
begin/end transactions) of the fact so it rolls back (if execution has
branched by errorhandling). I'm not sure, however, if this might cause
unwanted side-effects as someone might be depending on this behaviour to
recover from the exception in the excpetion handler and flushing anyway.
Probably not a change we should make in 1.0bX due it's risks IMO.
I believe that for the time-being your best bet is to explicitly clear the
session if tg_excpetions is not None.
We could also make the transaction object available at the request so you
can manually roll it back instead of clearing the session (looks cleaner
and more explicit to me).
{{{
#!py
def index(self, ...):
if tg_excpetions is not None:
cherrypy.request.tg_sa_transaction.rollback()
...
}}}
Try the attached patch see if it helps and if so I can commit it (I can't
think of any imaginable way it could break existing (users) code (apart
from the obvious non-probable name clash of {{{tg_sa_transaction}}} ;) ).
Alberto
--
Ticket URL: <http://trac.turbogears.org/turbogears/ticket/1185>
TurboGears <http://www.turbogears.org/>
TurboGears front-to-back web development
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Tickets" 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-tickets?hl=en
-~----------~----~----~----~------~----~------~--~---
