[asterisk-dev] Deprecation of cdr_mysql

[Tilghman Lesher]

On Wed, Jul 11, 2012 at 2:52 PM, John Fawcett <john.ml at erba.tv> wrote:
> 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.
>
> 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.

Yes, it's funny how commercial software is so much slower when you ask
them to use a common framework.  It's almost as if they want you to
see a massive improvement in locking you into their native drivers or
something.  The benchmark means very little, because you're going
through a completely different ODBC driver layer (MS-ODBC vs
UnixODBC), separately written, separately maintained, and oh by the
way, Microsoft wants you to use their native .NET layer, too, not the
legacy ODBC layer.

Given that I know what the ODBC driver is doing (I've dissected it
multiple times, looking for bugs), the idea that the "layer" will make
anything other than a marginal difference in Asterisk is ludicrous.
Yes, it'll be slightly slower.  But it should not be anything near as
large as what the above benchmark showed.

-Tilghman