<p>Dennis <strong>uploaded patch set #4</strong> to the change originally created by Sean Bright.</p><p><a href="https://gerrit.asterisk.org/c/asterisk/+/19534">View Change</a></p><pre style="font-family: monospace,monospace; white-space: pre-wrap;">cel_odbc: Rewritten most of cel_odbc<br><br>We found that if a datasource is unavailable when cel_odbc.conf is<br>processed, the table is skipped and no records will ever be inserted<br>into the skipped table.<br><br>While splitting code apart, I found lots of interesting problems<br>hidden inside this file and ended up rewriting most of it. Trying to<br>keep changes minimal became a near impossible task because of the<br>amount of collisions and rewrites.<br><br>The first problem I encountered was malloc tricks and pointer hacks,<br>stuffing null-terminated strings below structures. As these structures<br>were only created when cel_odbc.conf is parsed, the loss of<br>maintainability far outweighs any performance gained from doing so.<br><br>Next, I split up all the massive functions best I could. Each function<br>now has its own exact purpose. Some functions were renamed during this<br>process to better describe what they do.<br><br>I also renamed many variables to what they really are/contained.<br>Redundant logging of allocation failures was removed as ast_calloc<br>already logs them. Functions were added to allocate and initialize<br>every structure with proper default values. Lots of temporary<br>variables were removed, avoiding extra string copies.<br><br>Arbitrary length limits on strings have been mostly removed.<br>Configuration file is now traversed instead of scanned repeatedly.<br><br>The SQL_ERROR return code from SQLFetch is now handled properly,<br>causing the table to be skipped instead of trying to perform partial<br>inserts into it.<br><br>Optimizing odbc_log() was fairly interesting and while I haven't<br>benchmarked should be fairly fruitful. The original algorithm<br>constructed completely new SQL for every table on every event,<br>stringifying values in the process and performing<br>events*tables*columns*20-ish string comparisons. The new algorithm<br>generates static queries once tables columns are known. Relative<br>addresses are generated for all parameters, to be used later when<br>binding parameters. By binding parameters instead of stringifying them<br>we allow the driver to decide on the most optimal conversion.<br><br>All identifiers have been wrapped with delimiters as specified by<br>driver, which should close any tickets related to column names and<br>reserved words.  Because we no longer perform type checks on all<br>columns, I was able to discard lots of extra data from the columns<br>struct.<br><br>Lastly, I tried to make verbose logs a bit more clear and useful.<br><br>Hopefully I was able to re-implement the "static", "filter" and<br>"alias" features properly. Documentation on how they actually function<br>was somewhat light.<br><br>This module now works as follows:<br><br>First, it reads the configuration file and stores all relevant bits in<br>structures for later. Once this is done, it will attempt to retrieve<br>column names for every table mentioned in the config file, construct a<br>query for these tables and pre-bind any parameters.<br><br>For any tables that were inaccessible at config time, a manager thread<br>will go through the list of tables every 10 seconds and attempts to<br>construct queries for any tables that this module failed to connect to<br>previously.<br><br>ASTERISK-29012 #close<br><br>Change-Id: Id85d81add33096f8282d212daf239f2fc845d783<br>---<br>M cel/cel_odbc.c<br>M configs/samples/cel_odbc.conf.sample<br>2 files changed, 956 insertions(+), 682 deletions(-)<br><br></pre><pre style="font-family: monospace,monospace; white-space: pre-wrap;">git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/34/19534/4</pre><p>To view, visit <a href="https://gerrit.asterisk.org/c/asterisk/+/19534">change 19534</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.asterisk.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.asterisk.org/c/asterisk/+/19534"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: asterisk </div>
<div style="display:none"> Gerrit-Branch: 18 </div>
<div style="display:none"> Gerrit-Change-Id: Id85d81add33096f8282d212daf239f2fc845d783 </div>
<div style="display:none"> Gerrit-Change-Number: 19534 </div>
<div style="display:none"> Gerrit-PatchSet: 4 </div>
<div style="display:none"> Gerrit-Owner: Sean Bright <sean@seanbright.com> </div>
<div style="display:none"> Gerrit-Reviewer: Friendly Automation </div>
<div style="display:none"> Gerrit-CC: Dennis <dennis.buteyn@xorcom.com> </div>
<div style="display:none"> Gerrit-MessageType: newpatchset </div>