| Summary: | ASTERISK-21035: [patch] - features.conf in static realtime requires distinct cat_metric for each parking lot | ||
| Reporter: | Alex Epshteyn (aepshteyn) | Labels: | |
| Date Opened: | 2013-02-01 15:17:42.000-0600 | Date Closed: | 2013-03-13 09:15:58 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Addons/res_config_mysql |
| Versions: | 1.8.20.0 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | CentOS, res_config_mysql backend | Attachments: | ( 0) asterisk-21035-orderby.diff ( 1) cli ( 2) static_db.sql |
| Description: | when multiple parking lots are defined in static realtime even though each parking lot has a distinct category but cat_metric is the same for all parking lots produces errors during configuration load or "features reload". Making cat_metric unique for each parking lot seems to solve the problem. It appears that the problem may be related to the order of loading of the configuration data (tested only using res_config_mysql) | ||
| Comments: | By: Michael L. Young (elguero) 2013-02-01 21:49:08.958-0600 What is the error message? Can you provide a debug log? https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information Thanks By: Alex Epshteyn (aepshteyn) 2013-02-02 00:19:13.710-0600 attaching 2 files 1) cli - error messages in cli 2) static realtime table that we use (id and tenantid are thirdlane specific columns, you can get rid of them) - i just left everything as is as I mentioned before - a workaround would be to specify a cat_metric value (unique for each parking lot but the same for all rows of a parking lot), but i don't think that it should be required - if I understand the purpose of cat_metric correctly By: Michael L. Young (elguero) 2013-02-03 22:56:26.658-0600 Give this patch [^asterisk-21035-orderby.diff] a try and see if that solves the problem. By: Rusty Newton (rnewton) 2013-02-18 09:36:38.045-0600 Alex were you able to try Michael's patch? By: Matt Jordan (mjordan) 2013-03-07 10:19:54.688-0600 Despite the lack of verification, the patch seems like it would fix the issue reporter's problem. Kicking this into Open. | ||