* Cédric Krier [2011-05-12 12:58 +0200]:
>You did not understand.
>I mean the current "required" parameter on Float fields means "!=
>0". And in this possible migration we will replace the meaning of
>"required" by a new parameter "nonzero". And I think it will be a
>good idea to have as default value for the new "required"
>parameter "True" like that we keep the same behavior by default.
You're not clear. What do you mean ? You want to rename "required"
to "nonzero" for numerical fields ? If so then this will no settle
the situation.
Or maybe you want to add a nonzero parameter. Which does not seems
useful to me.
Again, required attribute on Float fields doesn't mean "not null". It
means "non zero". And this feature is important because we used in
many places (I counted 45 fields using this feature) where we don't
allow zero as value.
I know this is not the right name.
So we can rename it into nonzero if we add a required attribute that
means "not null".
That's what I understood. As I said only renaming will not change the
situation, only make it worse. I like the idea of having the required
attribute having the usual meaning and adding the client side
validation.
>For me, there is no ambiguity once you accept that a Float field
>will always have a float value.
A Float field should only have a numerical value if it is required
to do so. Do you expect Date Field to always have a date value so
that you can do all kind of date operation on them ? Do you expect
Many2One field to have a non NULL value ? No, unless those fields
are required.
I think that it should work the same way for numerical fields.
There is also a big issue when accepting null in float field, it is
that SQL doesn't SUM (or other operation) between float and NULL.
Indeed.
But this could be fix in numerous way.
>In the business application world, I really think there are few
>places where we need to deal with "unknown" values.
Every non required field could be "unknownable".
But this is not possible for almost all the fields (see the list).
The goal of this change is to remove one ambiguity. I know that it is
not possible to do it for all fields.
If you want them to have a value (whatever it is) then the field
must become required.
What I want to say is that it is a feature not very important and
compared to the time it will take to implement/test, there is really
a lot of other stuffs to do.
Maybe it is not the most important, but there is a small conceptual
problem there.
--
Nicolas Évrard
B2CK SPRL
rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
E-mail/Jabber: [email protected]
Website: http://www.b2ck.com/
--
[email protected] mailing list
