[asterisk-dev] Asterisk 1.6 Realtime Database must use ', ' not '|' (was: Re: asterisk-dev Digest, Vol 46, Issue 47)

Matthew Rubenstein email at mattruby.com
Fri May 23 13:22:26 CDT 2008

On Fri, 2008-05-23 at 21:07 +0300, Atis Lezdins wrote:
> On Fri, May 23, 2008 at 8:44 PM, Matthew Rubenstein <email at mattruby.com> wrote:
> >        Breaking an API, especially one so fundamental but buried in nested SQL
> > code/strings as the DB field delimiter, is a very drastic step. Even if
> > deprecation of the old API were clearly documented (and I haven't seen
> > yet that it is, in a practical way), complaints from people whose code
> > depends on the old API should of course be heeded by the developers. So
> > far the justification has been that it's a feature that benefits future
> > Asterisk users, but there's no weigh in against the costs to existing
> > Asterisk users.
> >
> >        A well supported product would include a tool for upgrading SW that's
> > dependent on a deprecated API into the new API, to mitigate the costs to
> > existing users. Such a tool, even a rudimentary one that works only on
> > bundled example code, would probably find a lot more third party
> > contributions to making it work on other code in the wild than is just
> > the "my way or the highway" insistence that complaints about the API
> > change come with patches or be ignored.
> >
> >        There are all kinds of "open". Some open projects are read only, some
> > are read/write to a closed group, some are read/write to the public. And
> > read/write can apply to the code, to the repository of separate
> > contributions, to the documentation. And to the design and policy
> > process, "open minded". Asterisk is generally more open minded than this
> > API change and the manner of its design is playing out.
> Following this thread, but don't want to participate flame-war.. It's
> not comfortable for me to change (as i want ability to roll-back from
> 1.6 immediately), but here's a convert tool (supposing you don't
> really have TAB in your realtime config):
> UPDATE extensions_table SET appdata=REPLACE(appdata,'\|',CHAR(9));
> UPDATE extensions_table SET appdata=REPLACE(appdata,',','\,');
> UPDATE extensions_table SET appdata=REPLACE(appdata,'|',',');
> UPDATE extensions_table SET appdata=REPLACE(appdata,CHAR(9),'|');

	That's a good start, but the real problem is the SQL strings embedded
in code that's integrated with Asterisk Realtime apps, but isn't just
stored in the DB. If only all code and API formats were stored in a
relationald DB, API migrations would be a lot easier, but they're not.

> Regards,
> Atis

(C) Matthew Rubenstein

More information about the asterisk-dev mailing list