Summary:	ASTERISK-25032: [patch]cel_odbc sometimes inserts CEL with wrong eventtime
Reporter:	Etienne Lessard (hexanol)	Labels:
Date Opened:	2015-04-29 07:53:22	Date Closed:	2017-05-10 06:34:22
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	CEL/cel_odbc
Versions:	11.17.1 13.3.2	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) AST-25032.patch
Description:	Given I have a postgresql server with a "cel" table with a column "eventtime" of type timestamp Given I have cel_odbc configured to insert CEL in the "cel" table of my postgresql server When a CEL (struct ast_cel_event_record) is generated with eventtime.tv_usec between 1 and 99999, inclusively Then the record inserted in postgresql has the wrong eventtime For example, a CEL created at 1430309985.000009 will be inserted in postgresql with an eventtime of 1430309985.9. I took postgresql as an example, but the bug will show up for any DBMS with timestamp with sub-second precision. The bug does not show up if the column "eventtime" is of type varchar instead of timestamp. I wrote a small module to do some manual test: https://github.com/elessard1/asterisk-lab/blob/cel-odbc-wrong-eventtime/lab.c After compiling and loading the module, you can call "lab cel <us>" from the CLI, and it will generate a dummy CEL event with the given microsecond part.
Comments:	By: Etienne Lessard (hexanol) 2015-04-30 07:22:36.124-0500 I've attached a patch. In cel_odbc, when you are in the "case SQL_TIMESTAMP", it parse colptr (which is expected to be in a certain format) into its different component. At this stage, you don't know exactly the format of colptr; i.e. colptr could come from the "eventime" member of the CEL event or the "extra" member of the CEL event or it could come from a static value (doesn't make much sense I agree, but its possible). So you don't know if the time portion of colptr will have a fractional part, and if it does, what the precision will be (i.e. it could be .1 or .000001), so you can't parse it simply with %d. The patch parse the fractional part (if it exists) up to microsecond precision, and its this value that will be inserted in the DBMS. I've done some tests with postgresql (9.1) and mysql (5.5). By: Etienne Lessard (hexanol) 2015-04-30 07:24:18.154-0500 Patch for asterisk 11. By: Rusty Newton (rnewton) 2015-04-30 19:12:34.678-0500 Thanks for the contribution! If you'd like your contribution to be included faster, you should submit your patch for code review by the Asterisk Developer Community. To do so, please follow the Code Review [1] instructions on the wiki. Be sure to: * Verify that your patch conforms to the Coding Guidelines [2] * Review the Code Review Checklist [3] for common items reviewers will look for * If necessary, provide tests for the Asterisk Test Suite that verify the correctness of your patch [4] When ready, submit your patch and any tests to Review Board [5] for code review. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Code+Review [2] https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines [3] https://wiki.asterisk.org/wiki/display/AST/Code+Review+Checklist [4] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Test+Suite+Documentation [5] https://wiki.asterisk.org/wiki/display/AST/Review+Board+Usage By: Friendly Automation (friendly-automation) 2017-05-10 06:34:23.687-0500 Change 5589 merged by Jenkins2: cel_odbc:  Fix timestamp processing for microseconds [https://gerrit.asterisk.org/5589|https://gerrit.asterisk.org/5589] By: Friendly Automation (friendly-automation) 2017-05-10 07:09:59.612-0500 Change 5591 merged by Jenkins2: cel_odbc:  Fix timestamp processing for microseconds [https://gerrit.asterisk.org/5591|https://gerrit.asterisk.org/5591] By: Friendly Automation (friendly-automation) 2017-05-10 08:33:52.347-0500 Change 5590 merged by Jenkins2: cel_odbc:  Fix timestamp processing for microseconds [https://gerrit.asterisk.org/5590|https://gerrit.asterisk.org/5590]