Re: DBD::mysql next steps
Hi Pali! On Thu, Nov 16, 2017 at 12:49 PM, wrote: > Hi! And what are you going to do with all commits which you reverted in > 4.043 version? As I remember, months ago you wrote that you reapply > fixes, but nothing happened. Instead you started merging conflicting > new pull requests which other people opened on github. This just prevent > any future reintroduction of fixes which were already done and was > reverted. Or you going to invent wheel again? I'm really surprised that > you now want to throw out everything which I did, including security > fixes for SSL/TLS or new versions of MariaDB/MySQL (with huge test > setup). Otherwise I do not understand why you have not looked at > reverted commit yet... Or are you expecting that new after one year I > should start rebasing all my commits which I did on top of master and > opening pull requests again and again? Sorry, but this really look that > you are not interested in new supporting new MariaDB version and now is > really a good time to create a fork of DBD::mysql which would contains > support for new MariaDB, huge test coverage and security fixes for > SSL/TLS. As you might have seen I'm adding back the commits that were added between 4.041 and 4.042 piece by piece to the master branch. I'm trying to prevent breaking stuff so I'm moving slowly. I'm not expecting you to do any rebasing or sending new pull requests of code which we had already. I'll be applying the patches myself. Also, please note that the huge Travis setup and TLS fixes were really good and I absolutely am going to add this back to master. That said, I merged https://github.com/perl5-dbi/DBD-mysql/pull/181 which changes the bug tracker location to Github in the META.yml this morning; we don't need to merge everything exactly in order and accepting this pull request really does not make it impossible to later add the patches between 4.041 and 4.042 back to the code base. And of course we *NEED* to support libmysqlclient of MySQL 8 and also MariaDB, I can't see us making a new release to CPAN that would *NOT* support this. -- Michiel
Re: DBD::mysql next steps
On Friday 10 November 2017 10:13:55 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 > Hi! And what are you going to do with all commits which you reverted in 4.043 version? As I remember, months ago you wrote that you reapply fixes, but nothing happened. Instead you started merging conflicting new pull requests which other people opened on github. This just prevent any future reintroduction of fixes which were already done and was reverted. Or you going to invent wheel again? I'm really surprised that you now want to throw out everything which I did, including security fixes for SSL/TLS or new versions of MariaDB/MySQL (with huge test setup). Otherwise I do not understand why you have not looked at reverted commit yet... Or are you expecting that new after one year I should start rebasing all my commits which I did on top of master and opening pull requests again and again? Sorry, but this really look that you are not interested in new supporting new MariaDB version and now is really a good time to create a fork of DBD::mysql which would contains support for new MariaDB, huge test coverage and security fixes for SSL/TLS.
Re: DBD::mysql next steps
And I would suggest to disable issue tracker on github as primary bug tracker (according to DBD::mysql documentation) is on RT and also probably all problems are reported there. The worst thing which can be is to have two independent bug trackers, which is current situation.
Re: DBD::mysql next steps
Me too! I look forward to getting pull requests reviewed and in the driver as well as get your UTF-8 work in per my previous email. We can use all the help we can get. regards, Patrick On 11/11/17 3:53 AM, p...@cpan.org wrote: On Friday 10 November 2017 10:13:55 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 Great! Thank you very much, I'm waiting for a new action which would bring DBD::mysql back to the active development.
RE: DBD::mysql next steps
Just a thought, also add another flag to explicitly use the buggy code even if it is the default. That option would just suppress the warnings for now. ('mysql_enable_depreciated_unicode' vs 'mysql_enable_proper_unicode') If the warnings are annoying enough it gives the users of the "depreciated" code base an incentive to review their code to at least turn off the warnings and start thinking about fixing their code. Then eventually if you use the "depreciated", or don't use the "proper" option, you could just abort the code with an error message saying to downgrade DBD::mysql to a specific release. It should be fairly strait forward to downgrade DBD::mysql at that point. Curtis Leach | Lead EngineerO 702-494-4562 One Harrah's Court | Las Vegas, NV 89119www.caesars.com -Original Message- From: Darren Duncan [mailto:dar...@darrenduncan.net] Sent: Friday, November 10, 2017 6:39 PM To: dbi-users@perl.org Subject: Re: DBD::mysql next steps On 2017-11-10 5:58 PM, Dan Book wrote: > On Fri, Nov 10, 2017 at 8:43 PM, Noel Butler wrote: > Given that things are only ever going to move forward with my/maria-sql > would it not be better to enable this by default, and have a "disable" > setting for those who want to run something of antiques? > > Because in years to come there will only ever be the modern versions and > you;ll have to change default behavior then anyway, but since that time is > mostly here now, it makes more sense to enable it by default. > > No, this whole issue came about because existing code requires > modification to continue working. Requiring a new option to be set to > enable old behavior would cause the same problem. Backcompat is "forever". Yes, exactly. However, other things we CAN do include: 1. Prominently document the new switch with the strong recommendation that people flip it on by default in new code just as part of good housekeeping. Basically in the same vein as recommending use-strict or use-warnings without turning them on by default. This also means that all code examples for DBD::mysql should make sure to include setting the flag on. 2. After a reasonable but relatively short delay following the first version with this switch, make DBD::mysql issue warnings when it is used without turning that switch on. That should draw the attention of people that they need to update their code to work more properly but without actually breaking anything (unless someone uses warnings with FATAL, but then they asked for it). I say have a delay so that people who pay attention and would fix their code soon don't have reams of warnings appearing in their server logs. Although in general to keep the warning count down it could probably just be issued the first time a connection handle is used without the flag. 3. Make sure that at least the public or known Perl code using DBD::mysql and has reasonable control over use of the handle would turn the flag on. So Darkpan is mainly handled by #1 and #2 such as it can be. -- Darren Duncan
Re: DBD::mysql next steps
On Friday 10 November 2017 10:13:55 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 Great! Thank you very much, I'm waiting for a new action which would bring DBD::mysql back to the active development.
Re: DBD::mysql next steps
On 2017-11-10 5:58 PM, Dan Book wrote: On Fri, Nov 10, 2017 at 8:43 PM, Noel Butler wrote: Given that things are only ever going to move forward with my/maria-sql would it not be better to enable this by default, and have a "disable" setting for those who want to run something of antiques? Because in years to come there will only ever be the modern versions and you;ll have to change default behaviour then anyway, but since that time is mostly here now, it makes more sense to enable it by default. No, this whole issue came about because existing code requires modification to continue working. Requiring a new option to be set to enable old behavior would cause the same problem. Backcompat is "forever". Yes, exactly. However, other things we CAN do include: 1. Prominently document the new switch with the strong recommendation that people flip it on by default in new code just as part of good housekeeping. Basically in the same vein as recommending use-strict or use-warnings without turning them on by default. This also means that all code examples for DBD::mysql should make sure to include setting the flag on. 2. After a reasonable but relatively short delay following the first version with this switch, make DBD::mysql issue warnings when it is used without turning that switch on. That should draw the attention of people that they need to update their code to work more properly but without actually breaking anything (unless someone uses warnings with FATAL, but then they asked for it). I say have a delay so that people who pay attention and would fix their code soon don't have reams of warnings appearing in their server logs. Although in general to keep the warning count down it could probably just be issued the first time a connection handle is used without the flag. 3. Make sure that at least the public or known Perl code using DBD::mysql and has reasonable control over use of the handle would turn the flag on. So Darkpan is mainly handled by #1 and #2 such as it can be. -- Darren Duncan
Re: DBD::mysql next steps
On Fri, Nov 10, 2017 at 8:43 PM, Noel Butler wrote: > > Given that things are only ever going to move forward with my/maria-sql > would it not be better to enable this by default, and have a "disable" > setting for those who want to run something of antiques? > > Because in years to come there will only ever be the modern versions and > you;ll have to change default behaviour then anyway, but since that time is > mostly here now, it makes more sense to enable it by default. > No, this whole issue came about because existing code requires modification to continue working. Requiring a new option to be set to enable old behavior would cause the same problem. Backcompat is "forever". -Dan
Re: DBD::mysql next steps
On 11/11/2017 01:13, 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 Given that things are only ever going to move forward with my/maria-sql would it not be better to enable this by default, and have a "disable" setting for those who want to run something of antiques? Because in years to come there will only ever be the modern versions and you;ll have to change default behaviour then anyway, but since that time is mostly here now, it makes more sense to enable it by default. -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument
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