On 12/05/11 12:31 +0200, Nicolas Évrard wrote: > * Cédric Krier [2011-05-12 11:54 +0200]: > >On 12/05/11 11:35 +0200, Nicolas Évrard wrote: > >>* Cédric Krier [2011-05-12 11:03 +0200]: > >>>There is many more type of fields where the "unknown" value is not > >>>supported. > >>> > >>>So for me, there is no problem to implement the "unknown" value in > >>>Float fields but we need to keep the "not zero" mechanism and perhaps > >>>keep the default value for required True. > >> > >>I don't think this is a good idea. If a numeric field is required then > >>people have to input a value. There might be a good default defined in > >>the module but we don't know which value this is and we should not > >>choose one from one of the א0 value available in integer or (א1 if > >>we're talking about floats). > > > >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. So we can rename it into nonzero if we add a required attribute that means "not null". > >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. > >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". If you want them to > have a value (whatever it is) then the field must become required. But this is not possible for almost all the fields (see the list). 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. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgpNO9DRTc92b.pgp
Description: PGP signature
