Computed Fields broken by 1.99.2

[David Manns]

One of the recent releases has broken computed fields.

My application uses several instances of computed fields. They all
worked perfectly in 1.94.6 to which I have now reverted.

In 1.99.2 (and possibly intervening releases) the behavior of computed
fields is unpredictable. In my case, they are all computed correctly
when a new record is created (crud.create). However, when a record is
updated (crud.update) some of them are recomputed but others are not,
thus becoming inconsistent with the fields used in the computation.

This is in addition to application failures caused in 1.99.2 due to
the acknowledged replace_id problem (see
http://groups.google.com/group/web2py/browse_thread/thread/ddc384b33ec1a7cc/3935ecc0a6785e9e?lnk=gst&q=dgmanns#3935ecc0a6785e9e)
which caused me to spend lots of time finding a workaround.

This is all very alarming in a framework which boasts of "always
maintaining backward compatibility" - quote taken from the preface of
"the book".

Perhaps there is too much of a rush to add new features: not breaking
existing applications would seem to be of paramount importance.

A pity because in general, it is an outstanding platform.

[Bruno Rocha]

Please, can you share some parts of your models?

Specially an example of a computed field declaration and what are you using in compute=?, also it is important to have an example of what types the the other fields.

It is important to reproduce the problem for fixing (if a bug)

also, can you open a ticket in google code? code.google.com/p/web2py

Sometimes little things can break a little, but if it is detected as a bug or break of compatibility, for sure it will be fixed in few hours.

Thanks

--

Bruno Rocha

[http://rochacbruno.com.br]

[Anthony]

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

[Massimo Di Pierro]

I believe this is a bug and it has already been fixed in trunk and
nightly build. can you confirm?

[David Manns]

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:

[Richard Vézina]

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

[Alan Etkin]

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

[Richard Vézina]

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