Re: DBD::mysql path forward

On 9 November 2017 at 15:45, wrote: > On Thursday 09 November 2017 14:26:01 Peter Rabbitson wrote: >> On 11/09/2017 01:46 PM, Noel Butler wrote: >> >On 09/11/2017 21:32, p...@cpan.org wrote: >> > >> >> >> >>>What the complaints in this thread are focused on is what the *users* >>

Re: DBD::mysql path forward

Forking would take away my concerns (thank you all for suggesting that) but one thing pops into my mind: A decision to fork a mature module is not a light decision and should only be considered as a last resort (when ran out of all options). So far it is all based on the opinion of only one

Re: DBD::mysql path forward

I do not understand what (and how) your proposal with =2 solve. Probably nothing and people would again start after final release again complaining... On Friday 10 November 2017 09:24:35 Night Light wrote: > Forking would take away my concerns (thank you all for suggesting that) but > one thing

Re: DBD::mysql path forward

On 10 November 2017 at 13:11, wrote: > Should DBD::mysql maintainers now starting complaining to Oracle and > MariaDB, that they must revert their changes in MySQL and MariaDB, just > because DBD::mysql (as libmysqlclient application) stopped working, > because is misusing

Re: DBD::mysql path forward

On Friday 10 November 2017 07:59:05 Michiel Beijen wrote: > I'll stick with my earlier proposal - I'll propose to go back to the > *current* latest DBD::mysql release which does not break backcompat > for our users; add the patches that we discarded when we rolled back > one by one, such as

Re: DBD::mysql path forward

On Friday 10 November 2017 10:09:59 demerphq wrote: > Pali is there a concise summary of what we are arguing about here? Short summary: 1. There are applications which misuse perl and DBD::mysql internals to pass blob or utf-8 text data from perl to MySQL database. We were not aware of

Re: DBD::mysql path forward

You repeatedly expressed that you are not willing to maintain this module. This practically means that code is being asked to be released but somebody else needs to maintain it. Suggestions to change this code are next to that ignored. Questions to park the blocking encoding issue and at least go

Re: DBD::mysql path forward

On Friday 10 November 2017 13:40:40 demerphq wrote: > On 10 November 2017 at 13:11, wrote: > > Should DBD::mysql maintainers now starting complaining to Oracle and > > MariaDB, that they must revert their changes in MySQL and MariaDB, just > > because DBD::mysql (as libmysqlclient

Re: DBD::mysql path forward

You cannot go further without either breaking existing code. You *can* fix the code in a fork. This gives people the of switching to the fork when *they* want to. Or don’t switch. Seems to me forking is the only way forward. Just my 2c worth, having been exposed to these shenanigans of

DBD::mysql next steps

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

Re: DBD::mysql path forward

Technical: Reason why it does not help nor solve the main problem: Due to internals, DBD::mysql pseudo-randomly decide if input bind variable is encoded to UTF-8 or not. And do it independently of how is option enable_utf8 configured. As we know there are applications which misuse this internal.

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

Re: DBD::mysql next steps

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

minor changes in a parser

hello dear perl-experts, I'm pretty new to Programming and OO programming especially. Nonetheless, I'm trying to get done a very simple Spider for web crawling. the script below - is what i got to work it runs nicely : now i want to modify the script a bit - tailoring and tinkering is the way

Re: minor changes in a parser

This kind of stuff is trivial in Perl. You've chosen a good language. my $url =~ s|/bar$||; ...Which means: "Find any occurence of "/bar" at the very end of the URL and replace it with a nothing. This is called a "regex" ( short for "regular expression" ). We usually do regexes with