I had originally tried nearly the exact same code, only I had used
expunge() in stead of clear():
new_thing = Thing(name)
session.save(new_thing)
try:
session.flush()
except sa.exceptions.SQLError:
session.expunge(new_thing)
tg.flash("unable to create new thing with name %s" % name)
else:
name = None
return dict(name=name)
But when I did this, tg's attempt to flush/commit the session (as part
of its overall transaction) raised an exception stating that the
"transaction is inactive."
I apologize that I don't have actual code/stack transcripts here: in
an attempt to find a way around this problem, my code is quite
different now. I'll try to create a test case and show some output if
it's needed.
~jon
On Jun 7, 5:41 am, asm <[EMAIL PROTECTED]> wrote:
> Maybe I am missing something here and I cannot see your code; however
> my first thought is that you need to "flush" the session.
>
> This would be the session you imported (something) like this:
>
> from turbogears.database import metadata, session
>
> And the following excerpt would be an example of its use:
>
> try:
> record = User.get(user_id)
> user_name = record.user_name
> session.delete(record)
> session.flush( )
> tg.flash("User (%s) successfully deleted." %
> user_name)
> except sae.SQLError, sqle:
> tg.flash("User (%s) not deleted." % user_name)
> session.clear( )
> raise tg.redirect("list")
>
> Hopefully that won't have been mangled.
>
> To redirect back with all the uncommitted data is an interesting
> problem that held me up too. My way around it involves not raising a
> redirect exception but instead returning the results of a call to the
> form generating method. It sounds involved but is not really. If you
> want to follow this there is an example on page3 of my document on
> TinyMCE which can be found at:
>
> http://sureseam.webfactional.com/tgdocs/
>
> Happy hunting
> A
>
> On Jun 6, 10:27 pm, anderbubble <[EMAIL PROTECTED]> wrote:> By default,
> TurboGears wraps exposed controller methods in a
> > transaction that gets committed after the controller has run. This
> > commit can generate exceptions (most notably when the condition of
> > mapped objects violates an integrity constraint in the database). How
> > can I catch/handle these exceptions without turning off the automatic
> > transaction handling?
>
> > I have looked into using the exception_handler decorator (which might
> > not even work in this situation; I'm not sure) but that would disallow
> > access to the controller arguments.
>
> > The specific case that I am working with is an entity creation with a
> > duplicate name in a unique column. I want to be able to catch the
> > exception, flash and error message, and re-display the entry form
> > still filled in from their previous input.
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---