@validate vs. SQLAlchemy: problem with strange tracebacks

[Jan Niklas Fingerle]

Hi,

I'm using TurboGears 1.0b1. I've run into a problem when using
validation with SQLAlchemy.

Test cases:

SQLObject:

(1) I've quickstarted a project "testerrso" using SQLObject and without
identity.
(2) I've changed class Root in controllers.py to:

class Root(controllers.RootController):
@expose(template="testerrso.templates.welcome")
@validate(validators = {'v': turbogears.validators.Int})
def index(self, tg_error=None, **kwargs):
raise NameError
import time
log.debug("Happy TurboGears Controller Responding For Duty")
return dict(now=time.ctime())

(3) When directing my browser to the test app I get a traceback that
references my raise NameError => OK.

SQLAlchemy:

(1) I've quickstarted a project "testerrsa" using SQLObject and without
identity.
(2) I've changed class Root in controllers.py to:

class Root(controllers.RootController):
@expose(template="testerrsa.templates.welcome")
@validate(validators = {'v': turbogears.validators.Int})
def index(self, tg_errors=None, **kwargs):
raise NameError
import time
log.debug("Happy TurboGears Controller Responding For Duty")
return dict(now=time.ctime())

(3) When directing my browser to the test app I get a traceback that
looks like this:

Page handler: <bound method Root.index of <testerrsa.controllers.Root
object at
0x40b1ea6c>>
Traceback (most recent call last):
File
"/usr/local/lib/python2.4/site-packages/CherryPy-2.2.1-py2.4.egg/cherrypy
/_cphttptools.py", line 105, in _run
self.main()
File
"/usr/local/lib/python2.4/site-packages/CherryPy-2.2.1-py2.4.egg/cherrypy
/_cphttptools.py", line 254, in main
body = page_handler(*virtual_path, **self.params)
File "<string>", line 3, in index
File
"/usr/local/lib/python2.4/site-packages/TurboGears-1.0b1-py2.4.egg/turbog
ears/controllers.py", line 326, in expose
output = database.run_with_transaction(
File "<string>", line 5, in run_with_transaction
File
"/usr/local/lib/python2.4/site-packages/TurboGears-1.0b1-py2.4.egg/turbog
ears/database.py", line 292, in sa_rwt
retval = dispatch_exception(e,args,kw)
File
"/usr/local/lib/python2.4/site-packages/TurboGears-1.0b1-py2.4.egg/turbog
ears/database.py", line 269, in dispatch_exception
return errorhandling.dispatch_error(
TypeError: dispatch_error() got multiple values for keyword argument
'tg_errors'

Obviously my real exception becomes unrecognizable.

As far as I can suspect without digging too deep into the internals this
is somehow connected to so_rwt (database.py) just doing

[...]
try:
retval = func(*args, **kw)
[...]
except:
[...]
raise
[...]

and sa_rwt (same file) doing

[...]
try:
retval = func(*args, **kw)
[...]
except Exception, e:
transaction.rollback()
retval = dispatch_exception(e,args,kw)
[...]

=> so_rwt just re-raises the exception, sa_rwt dispatches it. I'm not
too much into things to understand the reason for this differing
behaviour. Anyway, using a "raise" in sa_rwt as will fixes the
problem for me. I'm not sure about side effects.

Should I open a ticket in trac, or is there something I'm missing?

Cheers,
--Jan Niklas

[Ksenia Marasanova]

You have tg_error in first example and tg_errors in second example, I
think this is the problem.

Ksenia.

[Jan Niklas Fingerle]

Hi,

Jan Niklas Fingerle wrote:
> SQLAlchemy:
>
> (1) I've quickstarted a project "testerrsa" using SQLObject and

s/SQLObject/SQLAlchemy/

sorry,
--Jan Niklas

[Jan Niklas Fingerle]

Hi,

Ksenia Marasanova wrote:
> You have tg_error in first example and tg_errors in second example,
> I think this is the problem.

yes, it seems i misspelled it when creating the small test cases, but
no, it doesn't solve the problem... :-(

Cheers,
--Jan Niklas

[Jan Niklas Fingerle]

Hi,

Jan Niklas Fingerle wrote:
> I'm using TurboGears 1.0b1. I've run into a problem when using
> validation with SQLAlchemy.

OK, since there seems to be no easy solution to this, I've just
created a trac ticket: http://trac.turbogears.org/turbogears/ticket/1118

The Version (1.0b1) was not available to select, so I left it
empty. Since this is an issue concerning the upcoming 1.0 release I
set the milestone to 1.0. I hope, this is OK.

Cheers,
--Jan Niklas