I just want to report here about this thread that it seems that computed field has to be set to readable and writable = True to make the computed field to be effectively computed on form submit. Computed field won't appears in form but will be computed. If not readable and writable True (I didn't test with only one of both paramaters, maybe only readable or writable True is enough) it will prevent the lambda to execute doesn't matter if all the fields required by the compute lambda are available to it.
Hope it could help other to better figure out how computed field works... I think book should be clearer about that, except if it's not the proper wait it should work... This is at least true for me under web2py 1.99.4 Richard On Fri, Jan 13, 2012 at 8:50 AM, Alan Etkin <spame...@gmail.com> wrote: > I think I was able to define readable auto computeable fields (fields > were able to re-compute themselves on insert or update, at least with > Sqlite) in the past. This is no longer supported (of course, if former > versions did)? > > On 17 nov 2011, 11:25, David Manns <dgma...@gmail.com> wrote: > > I have finally figured out the cause of my problem, though not why > > there was inconsistency in behavior with somecomputedfields updating > > and others not. I was putting writable=false and readable=false on > > thecomputedfields in my model. I'm not sure why I thought this was > > correct usage; it makes sense that readable=false might be needed to > > prevent thefieldfrom being displayed in forms, but given that the > > form won't show thefield, writable=false would be unnecessary. > > It seems that neither writable=false nor readable=false is needed > forcomputedfields, they appear to be automatically not displayed in > > SQLFORM andCRUD. Readable=false causes no harm but writable=false > > *MAY* cause thefieldto not be recomputed on update, though it will > > becomputedon record creation. This behavior is still present in the > > nightly build. > > The book could use some clarification in this area! > > David > > > > On Nov 17, 1:50 am, Massimo Di Pierro <massimo.dipie...@gmail.com> > > wrote: > > > > > I believe this is a bug and it has already been fixed in trunk and > > > nightly build. can you confirm? > > > > > On Nov 16, 8:23 pm, Anthony <abasta...@gmail.com> wrote: > > > > > > On Wednesday, November 16, 2011 8:39:54 PM UTC-5, David Manns wrote: > > > > > > > This is all very alarming in a framework which boasts of "always > > > > > maintaining backward compatibility" - quote taken from the preface > of > > > > > "the book". > > > > > > The intention was certainly not to break backward compatibility. If > > > > something isn't working the same, it's a bug, not a backward > compatibility > > > > violation (unless, of course, the original behavior was a bug and was > > > > simply being fixed). It's always a good idea to test upgrades before > > > > deploying to production, and if you find bugs, report them -- they > will > > > > usually be fixed very quickly. Even better, test out the nightly > builds or > > > > trunk from time to time, and report bugs before they make it into > stable > > > > releases. > > > > > > Anthony > > > > >
