Hello,
it seems that is some parts of the world it is required to have call duration with two decimals precision. By default acc module does the timestamp in seconds.
Thinking of adding an option to save the milliseconds, I see two option: - a new column to store the milliseconds part as integer - a new column to store the seconds.milliseconds as double
For those using various billing engines, what would be easier to digest when rating the CDRs?
There is already the option of doing db extra column to store $TV(Sn), but this value is stored in a string (varchar) format, giving a little more troubles to convert to numeric format before being able to compute duration, so it might just worth doing the C coding to store in right data type.
Cheers, Daniel
Hey,
On 10.08.2011 14:21, Daniel-Constantin Mierla wrote:
it seems that is some parts of the world it is required to have call duration with two decimals precision. By default acc module does the timestamp in seconds.
Thinking of adding an option to save the milliseconds, I see two option:
- a new column to store the milliseconds part as integer
- a new column to store the seconds.milliseconds as double
For those using various billing engines, what would be easier to digest when rating the CDRs?
Maintaining two columns for duration book-keeping seems cumbersome to me, I'd rather have a single column. In those cases where I don't need the milliseconds portion I just cut it off or round it. It's certainly easier to do than adding and converting values from two distinct columns (meaning more complex database queries) to achieve milliseconds precision, which is the more common case to me.
There is already the option of doing db extra column to store $TV(Sn), but this value is stored in a string (varchar) format, giving a little more troubles to convert to numeric format before being able to compute duration, so it might just worth doing the C coding to store in right data type.
Storing numerical values right away looks like The Right Thing to do.
Cheers,
--Timo
On Wednesday 10 August 2011 14:21:10 Daniel-Constantin Mierla wrote:
- a new column to store the seconds.milliseconds as double
Please don't use double, use a fixed point format. Double's are for scientific use, this is accounting so exact numbers are required.
In MySQL, one could use the DECIMAL type.
On Thursday 11 August 2011, Alex Hermann wrote:
On Wednesday 10 August 2011 14:21:10 Daniel-Constantin Mierla wrote:
- a new column to store the seconds.milliseconds as double
Please don't use double, use a fixed point format. Double's are for scientific use, this is accounting so exact numbers are required.
In MySQL, one could use the DECIMAL type.
Hi Alex,
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?
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.
Best regards,
Henning
On Thursday 11 August 2011, Henning Westerholt wrote:
On Thursday 11 August 2011, Alex Hermann wrote:
On Wednesday 10 August 2011 14:21:10 Daniel-Constantin Mierla wrote:
- a new column to store the seconds.milliseconds as double
Please don't use double, use a fixed point format. Double's are for scientific use, this is accounting so exact numbers are required.
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.
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.
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.
On Thursday 11 August 2011, Alex Hermann wrote:
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.
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.
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).
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
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.
Yes, I also looked it up. :-) Just wanted to give some context about the current support in the DB API.
Internal representation as string is ok as long as calculations are not necessary. Alternatively a scaled integer could be used internally.
Best regards,
Henning
-
Alex Hermann -
Daniel-Constantin Mierla -
Henning Westerholt -
Timo Reimann