[asterisk-dev] Deprecation of cdr_mysql

[Paul Belanger]

On 12-07-11 04:10 PM, Matthew Jordan wrote:
>
>
> ----- 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?
>
I definitely think moving a module from deprecated back to extended 
should be dependent on a new contributer maintaining it.  Rather then 
just people saying it should be changed.

So that said, if somebody wanted to take the time to fix the current 
issues in JIRA for cdr_mysql, have the code reviewed on reviewboard and 
merged back into Asterisk, I'd be more then happy to see the module 
moved into extended support.

Until that happens, my vote would be to keep it deprecated, since it was 
the lack of support that moved it there in the first place.

>
> 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
>
> --
> _____________________________________________________________________
> -- 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


-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: 
https://twitter.com/pabelanger