[asterisk-dev] Deprecation of cdr_mysql

John Fawcett john.ml at erba.tv
Wed Jul 11 14:52:48 CDT 2012


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.

John




More information about the asterisk-dev mailing list