I have finally figured out the cause of my problem, though not why there was inconsistency in behavior with some computed fields updating and others not. I was putting writable=false and readable=false on the computed fields 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 the field from being displayed in forms, but given that the form won't show the field, writable=false would be unnecessary. It seems that neither writable=false nor readable=false is needed for computed fields, they appear to be automatically not displayed in SQLFORM and CRUD. Readable=false causes no harm but writable=false *MAY* cause the field to not be recomputed on update, though it will be computed on 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
