[asterisk-bugs] [JIRA] (ASTERISK-30116) Asterisk cel DB table issues

Joshua C. Colp (JIRA) noreply at issues.asterisk.org
Thu Jun 23 03:56:49 CDT 2022


     [ https://issues.asterisk.org/jira/browse/ASTERISK-30116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua C. Colp updated ASTERISK-30116:
--------------------------------------

    Assignee: Dalius Mockevicius
      Status: Waiting for Feedback  (was: Triage)

Asterisk is writing something longer than it would have in the past when such a schema was created. You can extend the size further to meet your needs. Does that work? If so, for your usage what did you extend it to? Over all the CEL schema isn't managed using our current Alembic based system as noone has moved it there.

> Asterisk cel DB table issues
> ----------------------------
>
>                 Key: ASTERISK-30116
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30116
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CEL/cel_odbc
>    Affects Versions: 18.12.0
>            Reporter: Dalius Mockevicius
>            Assignee: Dalius Mockevicius
>
> Hello,
> I need information, whether is it bug, or undocumented feature.
> Curently I have Asterisk writing something CEL log to MySQL table. Table is created using these examples: https://wiki.asterisk.org/wiki/display/AST/CEL+Configuration+Examples
> There column `peer` has type varchar(80).
> Now I have these messages in Asterisk full log, e.g.:
> {code}
> [Jun 19 10:43:55] WARNING[16877] res_odbc.c: SQL Execute returned an error: HY000: [MySQL][ODBC 8.0(w) Driver][mysqld-5.7.37-40]Data too long for column 'peer' at row 1
> [Jun 19 10:43:55] WARNING[16877] res_odbc.c: SQL Execute error -1!
> [Jun 19 10:43:55] WARNING[16877] cel_odbc.c: Insert failed on 'asterisk-odbc:realtime_cel'.  CEL failed: INSERT INTO realtime_cel (eventtype, eventtime, userdeftype, cid_name, cid_num, cid_ani, cid_rdnis, cid_dnid, exten, context, channame, appname, appdata, amaflags, accountcode, peeraccount, uniqueid, linkedid, userfield, peer, extra) VALUES ('BRIDGE_EXIT', {ts '2022-06-19 10:43:55.747193'}, '', 'xxxxxxx', '000000000', '00000000', '', '000000000', 's', 'conference', 'SIP/sitea-vims-vln-in-000000f3', 'ConfBridge', '1234,conference,user_unmuted', 3, '', '', '1655620856.1543', '1655620856.1543', '', 'CBAnn/1234-00000016;2,SIP/sitea-vims-vln-in-000000f5,SIP/sitea-vims-vln-in-000000f6,SIP/sitea-vims-vln-in-000000f9', '{"bridge_id":"94ec9b5a-d85d-443f-84b6-5e792884cde6","bridge_technology":"softmix"}')
> {code}
> This is because peer value is 115 chars long. Longer than its is allowed by table schema.
> And my question is did I miss some DB migration? Or Asterisk writes something longer, than is expected?



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list