This:
PSDBrec = request.args[1]
PSDBrec.update_record(**dict(form.vars))
could never have worked. The ticket is right. PSDrec is a string.
This is the correct thing to do:
PSDBrec = db.PSDB(request.args(1)) or redirect(URL('error_page'))
PSDBrec.update_record(**dict(form.vars))
or faster (1 db IO vs 2 db IO)
db(db.PSDB.id==request.args(1)).update(**dict(form.vars))
On Dec 27, 1:34 pm, reyelts <[email protected]> wrote:
> Here's the complete traceback:
>
> Traceback (most recent call last):
> File "/media/EZTRAIN/web2py_lin/gluon/restricted.py", line 188, in
> restricted
> exec ccode in environment
> File "/media/EZTRAIN/web2py_lin/applications/canyonezt/controllers/
> client.py", line 245, in <module>
> File "/media/EZTRAIN/web2py_lin/gluon/globals.py", line 95, in
> <lambda>
> self._caller = lambda f: f()
> File "/media/EZTRAIN/web2py_lin/applications/canyonezt/controllers/
> client.py", line 234, in measure
> PSDBrec.update_record(**dict(form.vars))
> AttributeError: 'str' object has no attribute 'update_record'
>
> I figured out how to get around the problem. PSDBrec is a record id
> passed in as a result of selecting from a list. Going into the above
> code snippet, I simply had:
>
> PSDBrec = request.args[1]
>
> To get around the problem introduced by the upgrade, I replaced it
> with this:
>
> PSDBrec = db.PSDB(db.PSDB.id==request.args[1])
>
> The bigger problem is that the original implementation *worked* with
> 1.81.4. Every time we do an upgrade of the web2py structure, it seems
> we go through a couple days of hunting down and fixing this kind of
> stuff. It's getting very, very old. From the introduction to the book,
> we have this statement:
>
> Another feature of web2py is that we, its developers, commit to
> maintain backward
> compatibility in future versions. We have done so since the first
> release of web2py
> in October, 2007. New features have been added and bugs have been
> fixed, but if a
> program worked with web2py 1.0, that program will still work today.
>
> In the year or so I've been using web2py, I have yet to find a
> *single* case where this statement holds true. Granted, I don't pull
> every release... mostly only when I know I have a little free time to
> do some debugging to find things like this issue and the version file
> problem reported earlier.
>
> It is getting to be enough of a problem for me to consider reworking
> my code to use different framework. While web2py has it's advantages,
> the lack of any true upward compatibility is frustrating beyond
> explanation.
