[asterisk-dev] realtime odbc problem

[Dmitry Andrianov]

Hello.

[a followup of IRC discussion]

There is a hack in asterisk realtime allowing you specify multiple
values for the same parameter (like "allow" for example). To do that,
you just put semicolon separated values into the column and later
realtime_odbc function of res_config_odbc.c splits ANY value containing
semicolon into multiple values. So if col1 has "a;b;c" value,
realtime_odbc will return 

col1=a 

col1=b

col1=c

 

Since this split occurs on very low level, the higher level code (AEL in
dialplan) have no control over this. As result you will have problems if
some value in the DB column actually contains semicolon. Even where
semicolon does not separate anything, realtime_odbc will be using it as
delimiter generating multiple values (and breaking the only right
value).

Changing delimiter from semicolon to anything else does not look to be a
good solution - it just hides problem. The problem is that at
realtime_odbc level we do not know what value really contains - it is
just one of database columns. And we should not make any assumptions on
what we can do with it.

 

Only the higher-level code (code which parses parameters from configs)
understand what kind of data is in each parameter and which parameter
can have multiple values and which cannot.

 

So my proposal is:

1.       Remove code from realtime odbc which does the parameter
splitting

2.       Handle list of values in the places where these parameters are
processed (like build_peer of chan_iax2)

3.       Make coma default delimiter instead of semicolon because it
makes value lists more appealing. That is split by both of these but
warn user semicolon is deprecated if it is present in the value.

 

It looks like just a few parameters need to support value lists. From
quick look at chan_sip/chan_iax I found only allow/disallow, permit/deny
and "context" for IAX. (Also some parameters like auth/encryption
already support multiple values in one parameter).

 

Changes proposed should not break anything at all - users having
"ulaw;alaw" in the "allow" column will have these values properly parsed
(although warning will be issued saying they should use "alaw,ulaw"
instead. 

As a side effect (positive), users will also be able specifying

 

allow = alaw,ulaw

 

as a single line in the configuration file instead of using two lines.

 

What do you think?

 

Regards,

Dmitry Andrianov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20070927/455713b1/attachment.htm