Re: DBD::mysql next steps

[email protected] ("Patrick M. Galbraith") Fri, 10 Nov 2017 13:56:27 -0500
Newsgroups perl.dbi.dev
Message-ID <[email protected]>
Darren,

Yes, the other plan definitely had its merits. Credit due to Michiel on 
that plan who really helped lay it out and explain the pros and cons of 
each and helped me to get that idea out.

Kind Regards,

Patrick

On 11/10/17 12:24 PM, Darren Duncan wrote:
> I agree in principle with Patrick's plan.
>
> My strong recommendation for continuing development under a different 
> module name was based on the assumption (but not the knowledge) that 
> the Unicode/Blob problems were rooted in the DBD::mysql codebase in 
> such a way that they blocked the ability to use the newer 
> MySQL/MariaDB/etc client libraries properly and that maintaining 
> support for both behaviors user-configurable would be too difficult to 
> do without making bugs worse.
>
> However, I also believe that Patrick's proposal (a single DBD::mysql 
> under that name where the incompatible new behavior is toggled on a 
> per-connection switch) is actually the best and most elegant solution 
> for satisfying all parties under the assumption that there are savvy 
> developers who fully understand the problem and are able and willing 
> to support such a more-complicated codebase.
>
> -- Darren Duncan
>
> On 2017-11-10 7:13 AM, Patrick M. Galbraith wrote:
>> Greetings all!
>>
>> Michiel and I have been talking, weighing options of what course to 
>> take in
>> dealing with moving forward-- with the goal of both offering both 
>> stability
>> and the choice to have the latest functionality and bug fixes as well as
>> give contributors the opportunity to be part of overall improvements 
>> to the
>> driver.
>>
>> What we are going to do is:
>>
>> Add to the connection the ability to turn on proper UTF handling with
>> 'mysql_enable_proper_unicode'. This gives the user volition the 
>> option to knowingly
>> toggle whether they want the new functionality and understand that
>> data structures returned or accepted by the driver might be different
>> than without this setting.
>>
>> The other options had their merits, but we think this will solve the 
>> issue
>> while keeping the driver unified and prevent divergence.
>>
>> Thank you for your input over the last couple months-- we look 
>> forward to
>> moving ahead!
>>
>> Patrick and Michiel
>>