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 t
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 wrote:
> I have finally figured out
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
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
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 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 backw
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
so
6 matches
Mail list logo
