11 Aug
2011
11 Aug
'11
4:26 p.m.
On Thursday 11 August 2011, Alex Hermann wrote:
IMHO support should be added then. Floating point (on digitial equipment)
is not suitable nor acceptable (it might even be illegal in some
jurisdictions) for accounting.
I really wonder why DOUBLE support is(/would be) present in a SIP proxy.
Hi Alex,
good question - I guess as workaround for a lack of DECIMAL in old open source
database versions.
I think something similar is used related to the 'q' value for contacts, the
respective field in the location table is also floating point.
http://devel.kamailio.org/doxygen/QvalueHandling.html
Yes, I also looked it up. :-) Just wanted to give some context about the
current support in the DB API.
In MySQL, one could use the DECIMAL type.
there is currently no write functionality in the DB API and also scheme
generation XSL to support the DECIMAL type. If double is
not correct for
you, what about just storing the milliseconds as INT value e.g. 12,3s =>
123 in the DB?
Why try to invent a workaround? Fixed point number types are part of SQL92:
NUMERIC(precision, scale). BTW, only
db_mysql and db_unixodbc currently support DECIMAL value for
read, db_mysql evaluates it to DB1_STRING, db_unixodbc to DB1_INT.
I know. You committed the fix for MySQL yourself after my bugreport, see
commit b74e6f6. Internal representation as string is ok as long as
calculations are not
necessary. Alternatively a scaled integer could be used internally.
Best regards,
Henning