[asterisk-dev] Deprecation of cdr_mysql

[Paul Belanger]

On 12-07-11 04:42 PM, Olle E. Johansson wrote:
>
> 11 jul 2012 kl. 22:29 skrev 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.
>
> Paul,
> THe original creator of the module just wrote to the mailing list and said he wanted to do that.
> Can you please give him a chance before you pass any judgement.
>
I am giving him a chance :)  And if there is follow up on it, I'll be 
the first one to review the code, test and give feedback.

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