openerp-expert-framework team mailing list archive

[Georges Racinet <gracinet@xxxxxxxxx>]

On 08/26/2013 04:30 PM, Joël Grand-Guillaume wrote:
> Thanks for pointing that up. I didn't realize that the core was
> casting numeric to float.
Nor did I, there's always something to learn, isn't it ? But it showed
up pretty quickly when I started digging.
The thing is that fields.float(digits=something) will create a numeric
column in DB.

To point the obvious, this means that you can have exact computations
right now, as long as they are done in SQL, but you can't input very
large numbers.
Another benefit is that you may suit other applications interacting with
OpenERP through the DB, and be less shocking to other people that take
care of them, such as BI consultants.

And also, this means that I don't have to rush my decimal work into
production right now: having the correct DB schema is enough to get easy
later upgrades…

I've seen a few comments on the PostgreSQL mailing-lists that PostgreSQL
is perceived by its developers as an environment that can be safely be
shared by several applications, thanks to the high level of standards
compliance. Obviously, OpenERP is not the best of citizens with respect
to that kind of interoperability yet.

> So I though it might had been very useful to have a MP that provide a
> new field.decimal that everyone can use (especially for financial stuff).
>
> Now I understand why that's not possible... In an ideal world,
> field.float should be store as float in DB and field.decimal as numeric...
>
> Thanks for the work.
You're welcome : I need it anyway. Don't want bad business decisions and
angry users because of an exact comparison of floats failed by 1^-7, nor
do I want to chase developer's tails to check that any logic involving
non integer numbers uses appropriate rounds()

Regards,

-- 
Georges Racinet
Anybox SAS, http://anybox.fr
Bureau: 09 72 39 50 97 / 09 72 39 13 06
Portable: 06 51 32 07 27
GPG: 0x33AB0A35, sur serveurs publics