This has already been fixed some some time ago in trunk. It is now:

                if self.table[fieldname].type == 'boolean' and \
                    self.vars.get(fieldname,True) == None:
                    del self.vars[fieldname]
                continue


On Feb 2, 4:36 pm, Richard Vézina <ml.richard.vez...@gmail.com> wrote:
> Still waiting for a solution!!
>
> Richard
>
> On Wed, Feb 2, 2011 at 12:04 PM, Richard Vézina <ml.richard.vez...@gmail.com
>
>
>
>
>
>
>
> > wrote:
> > Can I just remove the added line in sqlhtml.py in the web2py 1.91.6?
>
> > Is it safe to do so?
>
> > I have crud.update form where I have some field that are boolean type that
> > are set to writable false then I use a .represent= for them...
>
> > Ex.:
> > db.table1.valid.represent=\
> >     lambda value: value==True and T('valid').capitalize() or T('not
> > valid').capitalize()
>
> > They got caught by the if and remove from the update form on submit as far
> > as I understand.
>
> > Richard
>
> > On Wed, Feb 2, 2011 at 9:10 AM, Richard Vézina <
> > ml.richard.vez...@gmail.com> wrote:
>
> >> True
>
> >> Richard
>
> >> On Wed, Feb 2, 2011 at 12:20 AM, Marin Pranjic 
> >> <marin.pran...@gmail.com>wrote:
>
> >>>                 ### this happens because FROM has no knowledge of
> >>> writable
> >>>                 ### and thinks that a missing boolean field is a None
> >>>                 if self.table[fieldname].type == 'boolean' and
> >>> self.vars[fieldname]==None:
> >>>                     del self.vars[fieldname]
>
> >>> these are in red
>
> >>> On Wed, Feb 2, 2011 at 12:19 AM, Massimo Di Pierro <
> >>> massimo.dipie...@gmail.com> wrote:
>
> >>>> Which ones are in red?
>
> >>>> On Feb 1, 1:13 pm, Richard Vézina <ml.richard.vez...@gmail.com> wrote:
> >>>> > Hello,
>
> >>>> > If I change erase those line (in red) in /gluon/sqlhtml.py
>
> >>>> >  if not self.ignore_rw and not self.table[fieldname].writable:
> >>>> >                 ### this happens because FROM has no knowledge of
> >>>> writable
> >>>> >                 ### and thinks that a missing boolean field is a None
> >>>> >                 if self.table[fieldname].type == 'boolean' and
> >>>> > self.vars[fieldname]==None:
> >>>> >                     del self.vars[fieldname]
> >>>> >                 continue
>
> >>>> > It solves the problem... But I don't have clue of what the impacts are
> >>>> on
> >>>> > web2py.
>
> >>>> > I use Postgres as backend...
>
> >>>> > I will try to write a demo app to reproduce de problem...
>
> >>>> > Richard
>
> >>>> > On Tue, Feb 1, 2011 at 12:49 PM, Richard Vézina <
> >>>> ml.richard.vez...@gmail.com
>
> >>>> > > wrote:
> >>>> > > Hello,
>
> >>>> > > I am not sure where it comes from the problem I face, but for sure
> >>>> it comes
> >>>> > > from 1.91.6 because I dont have the probleme with the exact same app
> >>>> under
> >>>> > > 1.88.2.
>
> >>>> > >  1.
> >>>> > > 2.
> >>>> > > 3.
> >>>> > > 4.
> >>>> > > 5.
> >>>> > > 6.
> >>>> > > 7.
> >>>> > > 8.
> >>>> > > 9.
> >>>> > > 10.
> >>>> > > 11.
> >>>> > > 12.
> >>>> > > 13.
> >>>> > > 14.
>
> >>>> > > Traceback (most recent call last):
>
> >>>> > >   File "/home/www-data/web2py/gluon/restricted.py", line 188, in
> >>>> restricted
>
> >>>> > >     exec ccode in environment
>
> >>>> > >   File
> >>>> "/home/www-data/web2py/applications/init/controllers/test.py", line 855, 
> >>>> in
> >>>> <module>
>
> >>>> > >   File "/home/www-data/web2py/gluon/globals.py", line 95, in
> >>>> <lambda>
>
> >>>> > >     self._caller = lambda f: f()
>
> >>>> > >   File "/home/www-data/web2py/gluon/tools.py", line 2297, in f
>
> >>>> > >     return action(*a, **b)
>
> >>>> > >   File
> >>>> "/home/www-data/web2py/applications/init/controllers/test.py", line 410, 
> >>>> in
> >>>> update
>
> >>>> > >     if form.accepts(request.vars, session):
>
> >>>> > >   File "/home/www-data/web2py/gluon/sqlhtml.py", line 1091, in
> >>>> accepts
>
> >>>> > >     if self.table[fieldname].type == 'boolean' and
> >>>> self.vars[fieldname]==None:
> >>>> > > KeyError: 'valid'
>
> >>>> > > I have a field name "valid" in my models... May be it conflict with
> >>>> the new
> >>>> > > DAL??
>
> >>>> > > Thanks
>
> >>>> > > Richard

Reply via email to