[asterisk-dev] Deprecation of cdr_mysql

[Matthew Jordan]

----- Original Message -----
> From: "John Fawcett" <john.ml at erba.tv>
> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
> Sent: Wednesday, July 11, 2012 2:52:48 PM
> Subject: Re: [asterisk-dev] Deprecation of cdr_mysql
> 
> On 07/11/2012 05:25 PM, Olle E. Johansson wrote:
> > 11 jul 2012 kl. 17:16 skrev Paul Belanger:
> >
> >> On Wed, Jul 11, 2012 at 10:38 AM, Mark Michelson
> >> <mmichelson at digium.com> wrote:
> >>> On 07/11/2012 09:02 AM, Paul Belanger wrote:
> >>>> On Wed, Jul 11, 2012 at 9:47 AM, Olle E. Johansson
> >>>> <oej at edvina.net> wrote:
> >>>>> I must have missed the discussion - can someone please explain
> >>>>> to me why
> >>>>> cdr_mysql is marked as deprecated in 1.8?
> >>>>>
> >>>> It started with this review[1] and turned into this wiki page[2]
> >>>>
> >>>> Basically there is a better way to do it (ODBC) and nobody
> >>>> wanted to
> >>>> maintain the module.  After Asterisk 11 drops, I suspect you'll
> >>>> see
> >>>> some patches starting to remove some of the deprecated modules
> >>>> from
> >>>> source.
> >>>>
> >>>> [1] https://reviewboard.asterisk.org/r/1181/
> >>>> [2]
> >>>> https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Support+States
> >>>>
> >>> Let me chime in and say that removing deprecated modules is
> >>> unlikely to
> >>> occur unless we have a suitable drop-in replacement that we are
> >>> willing to
> >>> support.
> >>>
> >> The argument could be made, the reason for it being moved to
> >> deprecated in the first place was because there is another module
> >> that
> >> can provide the same functionality.
> >>
> >> The reality is this is usually not the case.  Nine times out of
> >> ten it
> >> is because we no longer want to do bug fixes for said module.
> >>
> >> For example, look at app_meetme.  It is a deprecated module in
> >> favour
> >> of app_confbridge, however app_confbridge is not a drop in
> >> replacement.
> > Up until now we had the policy of not deprecating stuff that works.
> > and especially
> > not REMOVE functionality that users use.
> >
> > Removing meetme without having a drop in replacement would cause a
> > non-developer-friendly
> > reaction from the user base, which I'm sure that we don't want.
> >
> > Removing mysql and postgresql just because ODBC has drivers for it
> > doesn't help either.
> >
> > Talking about mysql, I just found an issue in the realtime mysql
> > driver. It's not reporting errors. I see
> > in the debug that asterisk failed to update a record, but the
> > manager setvar that use the
> > REALTIME() function happily reports "success"... Someone forgot to
> > send or read an error code
> > somewhere in the chain.
> >
> > Oh well, always cool stuff to do.
> >
> > /O
> > --
> > _____________________________________________________________________
> > -- Bandwidth and Colocation Provided by http://www.api-digital.com
> > --
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >     http://lists.digium.com/mailman/listinfo/asterisk-dev
> I hope that mysql modules do not get removed any time soon.
> 
> Freepbx expects to have cdr_mysql and (for some modules app_mysql) so
> if
> at some point the mysql modules disappear there could be a lot of
> installations that don't work any longer unless Freepbx updates to
> use ODBC.
> 
> ODBC access is typically slower than using the native connector. For
> mysql the difference may not be as much as for other database, but it
> is
> exists. I found a benchmark here
> http://www.devtoolshed.com/content/performance-benchmarks-odbc-vs-oracle-mysql-sql-server-net-providers
> though it relates to .NET and not the C connector.
> 

As Mark already alluded to, modules are rarely removed from the code base.
The only two that I can recall actually being removed were app_rpt and
chan_usbradio - and that was done because they were no longer being maintained
for Asterisk 1.8+, and did not compile with any of the supported release branches.
Even still, those modules were not removed without a large amount of healthy discussion
before hand, and not without fair warning.  If someone ever cleaned them up
and got them back into shape with the common coding guidelines, we'd be happy
to consider putting them back in as well.

Since people continue to want to use the MySQL modules, and others are willing
to provide support for the MySQL modules, I'll make an official motion to mark
these modules as extended support.

Does anyone disagree?


Note:
For those who are curious, the current issue counts for those modules are:

Currently deprecated:
cdr_mysql: 4 Open issues
app_mysql: 2 Open issues

Currently extended support:
res_config_mysql: 7 Open issues

--
Matthew Jordan
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org