There are two issues: - decimal would have to be supported but all backends to work properly - decimal is not supported by Python. If you retrieve a value from the db it would be converted to float and then you insert it in the db, you get a different value, unless you use the decimal class to represent it.
Is this much complication really worth the trouble? Massimo On Nov 12, 9:25 am, villas <[email protected]> wrote: > On Nov 12, 12:10 pm, DenesL <[email protected]> wrote: > > > ideal IS_DEC_IN_RANGE validator should also be based on DB back-end, > > definite values are easier but would limit values for otherwise > > limitless POSTGRESQL values. > > As this feature has already taken a long time to specify, my vote > would be to simplify it as much as possible to get it off the ground. > If it helps to implement it quickly, I would suggest we should go > with the following: > > 1. Decimal to be default (18,2) -- which seems to be lowest common > denominator of all the DBs. Assume 2 decimal places because I guess > 95% of requirement is for currency. > 2. On Sqlite, or other DBs which do not support Decimal, simply map > to Float so that apps will at least run. But document this thoroughly > as a limitation of Sqlite. > > In the future, there could be some kind of emulation for Sqlite > (maybe using integers) and also make the number of Decimal places > variable. However, my plea would be: let's not delay the > implementation of a simple Decimal field type just because it isn't > available for Sqlite. > > Just my 2c, thanks for listening :-) > > Regards, David --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
