Make the XML CDR Importer more resilient #6543
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So I discovered 2 things,
If a user adds the default config cdr-field-array with the content of a database field Let's pretend they want to show the xml_cdr_uuid column (for support purposes) - it could be any column (please don't argue with the column name, it is an example only), the SQL construction will fail as not Postgresql, Not MariaDB/MySQL allow having a column repeated twice. Adding array_unique() fixes this issue.
This one is for developers: If a developer wants to create more columns in the v_xml_cdr table and make them visible in the CDR app, common sense tells to add the default setting cdr-field-array to show it. As the code is now, this will look into the freeswitch variables and overwrite it with NULL. I am adding a condition that verifies if the value has been already assigned, if it is, it won't overwrite it. This allows any developer who may be interested in extending the CDR to simply extend the class without touching it; very handy to keep the original code untouched.