fields.decimal

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

fields.decimal

Georges Racinet
Hi,

We're working on a 7.0 project where we will need to have true decimal
field ie, ``numeric`` on PostgreSQL side, ``decimal.Decimal`` in Python
code.

It seems to me that addind a true fields.decimal class would be rather
easy, so I wonder if there are any known, solid, public implementations
before starting rolling out my own.

I know this has been a controversial question for years, but that is
none of our concern, except that it makes searching the web on that
subject somewhat harder.
To state things clearly, I'm not speaking of converting the mainline
addons to true decimal at all. That'd be a much different question.

Of course, any implementation we may come with will be public and fully
unit tested.

We need to have it, and migrate our own code to use it, by the end of
the week.

Thanks for any hint or comment.

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


_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp

signature.asc (915 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fields.decimal

Ferdinand Gassauer
On 08/05/2013 12:32 PM, Georges Racinet wrote:

+1
Hi,

We're working on a 7.0 project where we will need to have true decimal
field ie, ``numeric`` on PostgreSQL side, ``decimal.Decimal`` in Python
code.

It seems to me that addind a true fields.decimal class would be rather
easy, so I wonder if there are any known, solid, public implementations
before starting rolling out my own.

I know this has been a controversial question for years, but that is
none of our concern, except that it makes searching the web on that
subject somewhat harder.
To state things clearly, I'm not speaking of converting the mainline
addons to true decimal at all. That'd be a much different question.

Of course, any implementation we may come with will be public and fully
unit tested.

We need to have it, and migrate our own code to use it, by the end of
the week.

Thanks for any hint or comment.

Regards,



_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fields.decimal

Joël Grand-Guillaume @ CampToCamp
No hints on it, but I'm clearly in favor of implementing a "true" field.decimal in the core, thanks for the initiative !


On Mon, Aug 5, 2013 at 12:34 PM, ferdinand <[hidden email]> wrote:
On 08/05/2013 12:32 PM, Georges Racinet wrote:

+1
Hi,

We're working on a 7.0 project where we will need to have true decimal
field ie, ``numeric`` on PostgreSQL side, ``decimal.Decimal`` in Python
code.

It seems to me that addind a true fields.decimal class would be rather
easy, so I wonder if there are any known, solid, public implementations
before starting rolling out my own.

I know this has been a controversial question for years, but that is
none of our concern, except that it makes searching the web on that
subject somewhat harder.
To state things clearly, I'm not speaking of converting the mainline
addons to true decimal at all. That'd be a much different question.

Of course, any implementation we may come with will be public and fully
unit tested.

We need to have it, and migrate our own code to use it, by the end of
the week.

Thanks for any hint or comment.

Regards,



_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp




--


camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28



_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fields.decimal

Georges Racinet
On 08/16/2013 11:14 AM, Joël Grand-Guillaume wrote:
No hints on it, but I'm clearly in favor of implementing a "true" field.decimal in the core, thanks for the initiative !

(back from a week-long leave, and could not find time to send this for another week)

Thanks for the support, Joël !

I'm not sure what you mean with "true" in that context.

At this point, I do have a working implementation of a 'fields.decimal', with web counterpart. The core field itself is trivial, as you may expect. For now, it's at https://bitbucket.org/anybox/anybox.openerp.fields, if you're curious.
This is a Python distribution (with setup.py etc). I'm considering repackaging as an addon, but I should check various upgrade scenarios first to be sure that a before-hand import is not needed.

One thing that should be underlined is that the standard OpenObject server has some form of support for the ``numeric`` PostgreSQL columns and even creates some, but makes Psycopg2 cast everything into float. Changing that behaviour will affect the server globally, even if the decimal field is imported just once.
Currently, in "base" addons, only ``res.currency`` would be impacted by the change.

JSON and XML RPCs are supported by serialization as strings. This is good enough for basic user interaction.

The web field is not pushed yet and needs proper packaging as an addon. For current intents and purposes, it's not much more than FieldChar.
Of course it'll need proper l10n rules, so that 10^5 gets displayed and input as 100,000.00 for US people and as 100.000,00 for French people. I'm willing to hardcode the latter in a first run, because that's what I need immediately.

Regards,




On Mon, Aug 5, 2013 at 12:34 PM, ferdinand <[hidden email]> wrote:
On 08/05/2013 12:32 PM, Georges Racinet wrote:

+1
Hi,

We're working on a 7.0 project where we will need to have true decimal
field ie, ``numeric`` on PostgreSQL side, ``decimal.Decimal`` in Python
code.

It seems to me that addind a true fields.decimal class would be rather
easy, so I wonder if there are any known, solid, public implementations
before starting rolling out my own.

I know this has been a controversial question for years, but that is
none of our concern, except that it makes searching the web on that
subject somewhat harder.
To state things clearly, I'm not speaking of converting the mainline
addons to true decimal at all. That'd be a much different question.

Of course, any implementation we may come with will be public and fully
unit tested.

We need to have it, and migrate our own code to use it, by the end of
the week.

Thanks for any hint or comment.

Regards,



_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp




--


camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28



_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp


-- 
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

_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fields.decimal

Joël Grand-Guillaume @ CampToCamp
Hi Georges,

Thanks for pointing that up. I didn't realize that the core was casting numeric to float. 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.

Regards,

Joël





On Fri, Aug 23, 2013 at 2:06 PM, Georges Racinet <[hidden email]> wrote:
On 08/16/2013 11:14 AM, Joël Grand-Guillaume wrote:
No hints on it, but I'm clearly in favor of implementing a "true" field.decimal in the core, thanks for the initiative !

(back from a week-long leave, and could not find time to send this for another week)

Thanks for the support, Joël !

I'm not sure what you mean with "true" in that context.

At this point, I do have a working implementation of a 'fields.decimal', with web counterpart. The core field itself is trivial, as you may expect. For now, it's at https://bitbucket.org/anybox/anybox.openerp.fields, if you're curious.
This is a Python distribution (with setup.py etc). I'm considering repackaging as an addon, but I should check various upgrade scenarios first to be sure that a before-hand import is not needed.

One thing that should be underlined is that the standard OpenObject server has some form of support for the ``numeric`` PostgreSQL columns and even creates some, but makes Psycopg2 cast everything into float. Changing that behaviour will affect the server globally, even if the decimal field is imported just once.
Currently, in "base" addons, only ``res.currency`` would be impacted by the change.

JSON and XML RPCs are supported by serialization as strings. This is good enough for basic user interaction.

The web field is not pushed yet and needs proper packaging as an addon. For current intents and purposes, it's not much more than FieldChar.
Of course it'll need proper l10n rules, so that 10^5 gets displayed and input as 100,000.00 for US people and as 100.000,00 for French people. I'm willing to hardcode the latter in a first run, because that's what I need immediately.

Regards,





On Mon, Aug 5, 2013 at 12:34 PM, ferdinand <[hidden email]> wrote:
On 08/05/2013 12:32 PM, Georges Racinet wrote:

+1
Hi,

We're working on a 7.0 project where we will need to have true decimal
field ie, ``numeric`` on PostgreSQL side, ``decimal.Decimal`` in Python
code.

It seems to me that addind a true fields.decimal class would be rather
easy, so I wonder if there are any known, solid, public implementations
before starting rolling out my own.

I know this has been a controversial question for years, but that is
none of our concern, except that it makes searching the web on that
subject somewhat harder.
To state things clearly, I'm not speaking of converting the mainline
addons to true decimal at all. That'd be a much different question.

Of course, any implementation we may come with will be public and fully
unit tested.

We need to have it, and migrate our own code to use it, by the end of
the week.

Thanks for any hint or comment.

Regards,



_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp




--


camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28



_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp


-- 
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

_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp




--


camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28



_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: fields.decimal

Georges Racinet
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


_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp
Loading...