Numeric type in framework
The idea is to provide the support for the numeric type in the orm in order to store money and factor with great precision when needed and also to provide the ORM to store really high value for developing statistical modules.
My point of view is the following, we store data in the numeric format provided by almost SQL engine (And also supported by alchemy) and access it trough the ORM.
They will be two way to access numeric type.
By using the fields.float of the ORM and adding to it two optional parameters
numeric=True/False
precision=
It will store the numerical value with a maximal precision or to a precision set in a new parameter in the system config, or maybe we should use the precision set in the parameters.
And when we read the value, it we automatically return a float with the precision given in the parameters.
the other way to acces to the numeric value would be to add a field decimal
something like
fields.
This field type will return a Python Decimal instance. The Decimal instance value will be read and stored with the specified precision, the render_precision will be used to set the widget representation / precision in term of output input in the OpenERP client.
I'm looking forward to your answers
Regards
Nicolas
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
2 things here:
1. On blueprints, be very careful, launchpad doesn't notify anyone that they're created so you'll have to subscribe the people you think should see it, or they'll never even be aware of your blueprint.
2. Though it's not quite ideal (understatement of the day), the `NUMERIC` postgres type is already "supported" by the OpenERP ORM: float fields can take a ``digits`` keyword argument, which is a tuple of (precision, scale). If this field is used, then the field is backed by a NUMERIC(precision, scale) postgres column instead of a FLOAT8. Personally, I'd rather have floats always be floats, and a purpose-specific ``decimal`` as in your proposal (or even, why not, ``money`` since Postgres has such a type: http://
xmo
------------
+
+ 3. Agree very much to the idea of decimal/numeric precision,scale
+ fields. Need of the day. - Sharoon
------------
It's true that the digit argument exist in float, the blueprint intended to extend the signature in order to be able to access to unllimited numeric type. And also add default config values and commodities for the numeric support.
One of this commodity may be to be able to add a to_decimal converter on the float field.
I dont think we should use the money type as OpenObject want to be a generic framework. The numeric type is the most generic type to store decimal/numeric value, Postgres also support a decimal type, but it is not the case of all SQL engine. The Numeric type is more common and support a wide variety of number formatting. The field should better be name field.numeric and provide some commodity like to_int, to_float, to_string, but should alway receive a Python decimal type in entries. We may add some decimal helper in the tools part of the server.
If you agree with this point I will edit the blue print.
Nicolas
------------
A numeric/decimal type is more generic and OpenObject wants to be a generic framework, but OpenObject also deals with monetary values *a lot*, and it's an important field. I don't think it would hurt to have a special-case monetary field, which might be backed with a money type when available, or with a NUMERIC one when not *on top of* the decimal/numeric field you're suggesting here.
On the field name, numeric might indeed be a good name (considering how the other field types are called), but I disagree with the to_* methods: on the python sides of things, a fields.numeric would return a decimal.Decimal, and python already provides everything you need to convert back and forth between types:
>>> int(decimal.
1
>>> float(decimal.
1.5
>>> str(decimal.
'1.5'
Not to mention, apart from str/repr you generally shouldn't need to perform conversions, as computations on decimal types should only be performed between decimals and ints, and that works out of the box:
>>> decimal.
Decimal('2.5')
>>> 1 + decimal.
Decimal('2.5')
>>> decimal.
Decimal('3.0')
As far as the API is concerned, something simple, along Django's DecimalField type (http://
xmo
-------
It's OK for me not to provide to_* features.
For the money type why not, it can even be stored in a numeric entry in database. For my point of view one of the big advantage of money type would be to be able to set a uniform quantize policy (may be it may be set in a field parameter) in term of reading and writing money, this should be also be true in term of end user widget.
On other point with the numerical widget will be to thing of the different available way to input the data because python Decimal support a lot of string input.
Nicolas
-------
re money type, yeah I basically don't know jack about the handling of money but what I've read/seen makes me think it as fairly specific needs, and I've already seen strong suggestion for a "money types" pattern (e.g. http://
On the widgets front (numerical and/or money), I hadn't really considered it, so I have no opinion (yet, anyway).
