10 Aug
2011
10 Aug
'11
3:21 p.m.
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
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda
10 Aug
10 Aug
4:35 p.m.
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
11 Aug
11 Aug
10:26 a.m.
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.
--
Alex Hermann
3:16 p.m.
On Thursday 11 August 2011, Alex Hermann wrote:
On Wednesday 10 August 2011 14:21:10 Daniel-Constantin
Mierla wrote:
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
- 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.
4:06 p.m.
On Thursday 11 August 2011, Henning Westerholt wrote:
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.
On Wednesday 10 August 2011 14:21:10
Daniel-Constantin Mierla wrote:
there is currently no write functionality in the DB API and also scheme
generation XSL to support the DECIMAL type. - 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. 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.
--
Greetings,
Alex Hermann
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
4859
days inactive
4860
days old
5 comments
4 participants
participants (4)
-
Alex Hermann -
Daniel-Constantin Mierla -
Henning Westerholt -
Timo Reimann