Re: DBD::mysql next steps

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
>