[web2py] IS_DECIMAL_IN_RANGE

[Richard]

Hello,

I was under the impression that IS_DECIMAL_IN_RANGE(2.25, 5.25) would validate and prevent input having more places the number of places of min and max...

I am I wrong? Did it use to work like that in the past??

How can we make sure there is only a given number of places in an input?

Thanks

Richard

[Anthony]

On Friday, April 20, 2018 at 9:38:47 AM UTC-4, Richard wrote:

Hello,

I was under the impression that IS_DECIMAL_IN_RANGE(2.25, 5.25) would validate and prevent input having more places the number of places of min and max...

No, it just ensures that the value is greater than or equal to the min and less than or equal to the max. This validator has nothing to do with the number of decimal places.

Anthony

[Richard Vézina]

Realize that, though I am sure it use to managed it...

Anyway, I find it curious that even if I have field of type decimal(10, 2) for instance, if I insert 1.304, and submit the form it ends up with 1.304 in the read form (backend has 3 places).

How do we validated the number of places??

Richard

--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups "web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard Vézina]

It appears that it get silently "cropped/rounded" by the backend field type configuration... If I have field with 2 places in the backend and 3 places defined in the models and input 0.647, it will be stored as 0.65.

Do we have control over the rounding in web2py or it configure in the database engine??

Richard

[Anthony]

On Friday, April 20, 2018 at 2:30:22 PM UTC-4, Richard wrote:

Realize that, though I am sure it use to managed it...

Not going back to at least web2py 2.02, as far as I can tell.

 

Anyway, I find it curious that even if I have field of type decimal(10, 2) for instance, if I insert 1.304, and submit the form it ends up with 1.304 in the read form (backend has 3 places).

As far as I can tell, the decimal specification in the "type" argument to Field() is used only for migrations -- that is, when the DAL is creating the column in the database. If the backend is pre-existing with 3 decimal places and the DAL does not run any migrations, then the decimal specification will have no effect. It is not used for transforming input or output.

 

How do we validated the number of places??

You could create a custom validator. If the inputs are strings, you'll have to count the number of digits after the decimal point. If the inputs are Decimal objects, value.as_tuple().exponent will give you the significant digits (as a negative number).

Anthony

[Anthony]

On Friday, April 20, 2018 at 2:36:58 PM UTC-4, Richard wrote:

It appears that it get silently "cropped/rounded" by the backend field type configuration... If I have field with 2 places in the backend and 3 places defined in the models and input 0.647, it will be stored as 0.65.

Do we have control over the rounding in web2py or it configure in the database engine??

web2py has no control over what the database does (other than its ability to initially define the precision of the database column if web2py is used for a migration to create the database table). So, first make sure your database column is defined with the decimal precision you want.

On the web2py side, you can control the precision of the inputs however you want -- web2py will simply pass those inputs to the database.

Anthony

[Richard Vézina]

There seems to have some thing related to gae : https://github.com/web2py/pydal/blob/a7b7e4c11604d0b8b2de46e832469b78bfd7a1cf/pydal/helpers/gae.py#L16

I guess custom validator with quantize decimal parameters would do it.

I recall having use that for report porpuses, but was on the impression that web2py was validating places... But it clearly not doing it anymore

Richard

--

[Richard Vézina]

It maybe just me, but I kind of think that if my models says decimal(10, 2) it means that I don't want to store more than 2 places... Since my models should behave like the database table and column as they are just an abstraction of the later...

I know web2py offer alot of granularity control and flexibility over all this aspect, but I feel that there is a missing component to handle this particular aspect (rounding and enforcing "length" of numeric fields).

Richard

--

[Anthony]

On Friday, April 20, 2018 at 3:00:16 PM UTC-4, Richard wrote:

There seems to have some thing related to gae : https://github.com/web2py/pydal/blob/a7b7e4c11604d0b8b2de46e832469b78bfd7a1cf/pydal/helpers/gae.py#L16

That's just the means of storing and retrieving decimal data in the GAE datastore according to the field specification. It doesn't do any validating. GAE obviously works differently from an RDBMS, which has a schema.

Anthony

[Anthony]

On Friday, April 20, 2018 at 3:06:59 PM UTC-4, Richard wrote:

It maybe just me, but I kind of think that if my models says decimal(10, 2) it means that I don't want to store more than 2 places... Since my models should behave like the database table and column as they are just an abstraction of the later...

Well, if you let the DAL create the table in the database, then you do get values with the specified number of places. If not, there is nothing web2py can do to affect what is stored in the database. I suppose web2py could round the data once selected from the database. Maybe submit a Github issue.

Anthony

[Richard Vézina]

I hear you and I agree about that... I am just supprise that we have no control over rouding of what goes in the database as it is very critical in some use case with weird rounding spec that you could have in academic sometime for instance.

At some point I had extend field "length" to 10 places that way I was not having to refactor fields parameters as client change of idea and just round the data at retrieving so it might be the way to go about that.

This is as easy as :

represent=lambda value, row: '{0:.2f}'.format(value) if value else T('N/A')

It could might be more efficient if we configure it at Decimal quantize level, but I think you have to maniuplate it for each field so it might come to the same computing resource required.

Richard

--

[Anthony]

On Saturday, April 21, 2018 at 7:53:42 AM UTC-4, Richard wrote:

I hear you and I agree about that... I am just supprise that we have no control over rouding of what goes in the database as it is very critical in some use case with weird rounding spec that you could have in academic sometime for instance.

You certainly have control over the inputs. If you want to encode your input rules in the table definition to get automatic transformations upon insert/update, you can use (a) a custom validator, (b) the filter_in argument, or (c) the _before_* callbacks.

Anthony