To me it makes no sens that readable and/or writable = False prevent compute to get all the field present in the table definition...
I may completely not understand what writable and readable are for... I know that depend of how they are used (both false) the field will not be present at all into the form and we can't get the field into form.vars... No problem with that... But why compute is not getting the whole fields seems to me pretty strange... Maybe this behavior is to allow compute to silently failed if the improper input is passed (ex.: None) Thanks Richard On Thu, Nov 17, 2011 at 9:25 AM, 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 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 >
