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

[Dalius Mockevicius (JIRA)]

Dalius Mockevicius created ASTERISK-30116:
---------------------------------------------

             Summary: 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


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.:

[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"}')

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)