[asterisk-dev] tilghman: trunk r247787 - /trunk/channels/chan_sip.c

[Tilghman Lesher]

On Friday 19 February 2010 06:46:53 Tony Mountifield wrote:
> In article <E1NiE9D-0006zA-5x at wibble.digium.internal>,
>
> SVN commits to the Digium repositories <svn-commits at lists.digium.com> wrote:
> > Author: tilghman
> > Date: Thu Feb 18 15:42:53 2010
> > New Revision: 247787
> >
> > URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=247787
> > Log:
> > If the peer record is from realtime, it could be set to 0, due to MySQL
> > not representing NULL well in integer columns.
> >
> > NULL means the value is not specified for the column, which normally
> > means the driver uses whatever is the default value.  However, on MySQL,
> > placing a NULL in either a float or integer column results in a retrieval
> > of the 0 value.  Hence, users get an errant error on load.  This patch
> > suppresses that error and makes the value as if it was not there.
> >
> > Note that this cannot be done in the realtime driver, because the lack of
> > difference between NULL and 0 can only be intepreted correctly by the
> > driver itself.  If we did it in the realtime driver, then it would be
> > effectively impossible to set any realtime field to 0, because it would
> > act as if the field were unspecified and possibly take on a different
> > value.
>
> Whether or not the patch is useful, I don't know, but the above description
> of MySQL behaviour is surely wrong.
>
> MySQL is can easily distinguish between 0 and NULL in numeric columns.
>
> If you have the statement: row = mysql_fetch_row(result);
> then row[n]==NULL if the corresponding column contains an SQL NULL, but if
> the column contains a zero, row[n] points to the string "0".

Perhaps this is something that MySQL has finally fixed in later versions, but
at one time, this was indeed the problem.

> The information is not getting lost in MySQL, but probably in
> res_config_mysql.c in one or more of the functions realtime_mysql(),
> realtime_multi_mysql() and config_mysql(), where a NULL is being converted
> to an empty string. Such a string will indeed yield a numeric 0 if you give
> it to something like strtoul().

This is actually a conversion for the realtime framework, and it's converted
back into effectively NULL at the next level, if the API used is
ast_load_realtime().  This was to deal with an issue where somebody iterated
over results in the dialplan and were surprised when NULL-value columns did
not overwrite expected variables in the dialplan.

-- 
Tilghman Lesher
Digium, Inc. | Senior Software Developer
twitter: Corydon76 | IRC: Corydon76-dig (Freenode)
Check us out at: www.digium.com & www.asterisk.org