Summary:ASTERISK-04926: [patch] RES_ODBC Sanity Check [back from the grave]
Reporter:Anthony Minessale (anthm)Labels:
Date Opened:2005-08-29 12:24:52Date Closed:2011-06-07 14:10:06
Versions:Frequency of
Environment:Attachments:( 0) res_odbc_sanity_rev0.diff.txt
Description:This patch was lost under the rug cos it was tacked onto an old bug that was closed.

This implements the config option sanitycheck => X in res_odbc.conf

set it to 1 to check when an error is encountered
set it to 2 to check everytime an odbc object is fetched

1 is the default behaviour

The issue here is if you wait for a fail you have a chicken/egg kanundrum because the reconnect invalidates your prepared statment so you would need to go back in time and rexecute a bunch of code which would require a setjump longjmp nightmare or something.  So when you absoultely need to make sure you have the best chance of getting a SQL stmt to execute on a connected server you would set sanitycheck => 2 if you can live with losing some here and there then leave it alone and use default.


ODBC related stuff has no category so I picked core/general

Disclaimer On File
Comments:By: Kevin P. Fleming (kpfleming) 2005-08-31 17:36:47

This is quite confusing; sanitycheck would appear to have only two valid values, but they do not match the syntax used for every other option in Asterisk (where values start with zero). In fact, if the user does set 'sanitycheck=0' thinking that it will turn this off, it won't. Since you don't allow obj->sanitycheck to be zero (new_odbc_obj sets it to 1 if it comes in as zero), there is not really any need to test obj->sanitycheck for being non-zero; it only matters if it is 1 or higher than 1, right?

On top of that, you reset the 'connect' and 'sanitycheck' variables every time you go through the ast_variable_browse() loop, so I don't see how their values could actually have any effect unless they are the last variables processed from the config.

Can we just make this use 'sanitycheck=0' is the existing behavior, and 'sanitycheck=1' is the new behavior, leaving values higher than one for higher levels of checking in a future patch?

By: Michael Jerris (mikej) 2005-09-25 16:08:42

suspended due to no response.  Please re-open with response.  Thanks.