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

Re: DBD::mysql path forward

I followed the discussion silently so far as I‘m not a user of DBD:mysql. If the changes are breaking I‘d also think a new distribution is the way to go. What about DBD::MariaDB as that‘s the name of the OpenSource version these days? Best regards, Alex > Am 10.11.2017 um 07:16 schrieb Darren

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 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 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

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

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 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

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

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

On 2017-11-09 10:50 PM, Alexander Hartmaier wrote: What about DBD::MariaDB as that‘s the name of the OpenSource version these days? No, MariaDB is simply a fork of MySQL. Both MariaDB and MySQL are Open Source. Saying only MariaDB is open source is wrong. I also disagree with using the

Re: DBD::mysql path forward

Michael, why can't you accept moving forward under a new module name? Why does it have to be under the old name? When people purposefully want to upgrade they purposefully choose the new module name in order to do so. What is the actual problem in that? -- Darren Duncan On 2017-11-09 10:59

Re: DBD::mysql path forward

Hi Darren, Dan, On Fri, Nov 10, 2017 at 7:16 AM, Darren Duncan wrote: > On 2017-11-09 8:32 AM, Dan Book wrote: >> >> It seems to me like the remaining option that can make everyone "happy" is >> the >> previously-suggested option of maintaining a legacy branch and doing

Re: DBD::mysql path forward

On 2017-11-09 8:32 AM, Dan Book wrote: It seems to me like the remaining option that can make everyone "happy" is the previously-suggested option of maintaining a legacy branch and doing new development (reinstating 4.042) in another branch which will be released as a new distribution, like

Re: DBD::mysql path forward

Pali, there's a very simple solution to what you said. The old DBD::mysql does not get further maintenance at all. It is simply frozen at the 4.041/3 state forever. This serves the primary reason for that to exist, which is that people whose package managers automatically upgrade to the

Re: DBD::mysql path forward

On 2017-11-09 12:54 AM, p...@cpan.org wrote: On Tuesday 07 November 2017 13:19:23 Darren Duncan wrote: The whole discussion on the mailing lists that I recall and participated in seemed to consensus on branching DBD::sqlite in order to best satisfy the

Re: DBD::mysql path forward

It seems to me like the remaining option that can make everyone "happy" is the previously-suggested option of maintaining a legacy branch and doing new development (reinstating 4.042) in another branch which will be released as a new distribution, like DBD::mysql2, by the same maintainers. (I

Re: DBD::mysql path forward

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* > >>>want. > >and the users want now, or will need in the near

Re: DBD::mysql path forward

On 11/09/2017 09:54 AM, p...@cpan.org wrote: As those people or projects misuse some internals of perl we cannot guarantee anything such that which may be broken or changed by updating any module from cpan or external source not related to DBD::mysql. Pali. This "argument" applies to a large

Re: DBD::mysql path forward

On Thursday 09 November 2017 13:01:19 H.Merijn Brand wrote: > On Thu, 9 Nov 2017 12:32:00 +0100, p...@cpan.org wrote: > > > > Satisfy the above - and you do get the privilege of being a maintainer > > > of a central module with 15+ years of history. > > > > Why should I be interested in

Re: DBD::mysql path forward

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* want. and the users want now, or will need in the near future, to build with latest, stable and recommended versions of MariaDB and

Re: DBD::mysql path forward

On 09/11/2017 21:32, p...@cpan.org wrote: >> What the complaints in this thread are focused on is what the *users* want. and the users want now, or will need in the near future, to build with latest, stable and recommended versions of MariaDB and MySQL. Code changes all the time with

Re: DBD::mysql path forward

On Thu, 9 Nov 2017 12:32:00 +0100, p...@cpan.org wrote: > > Satisfy the above - and you do get the privilege of being a maintainer > > of a central module with 15+ years of history. > > Why should I be interested in maintaining something from which users > want impossible things? "I can

Re: DBD::mysql path forward

On Thursday 09 November 2017 10:32:57 Peter Rabbitson wrote: > On 11/09/2017 09:54 AM, p...@cpan.org wrote: > > > >As those people or projects misuse some internals of perl we cannot > >guarantee anything such that which may be broken or changed by updating > >any module from cpan or external

Re: DBD::mysql path forward

Hi! I'm responding below. On Tuesday 07 November 2017 13:19:23 Darren Duncan wrote: > Patrick and Pali, each of you please respond to the lists to confirm that > what I say below is what you also understand is the primary plan, and if > not, then say why not; in prior discussion I recall you

Re: DBD::mysql path forward

Darren, Thank you. Yes, you are correct about prior discussions. How do we handle releases of having a DBD::mysql and a DBD::mysql2, in terms of people knowing "this is the old branch with no possibly breaking changes" vs. "this is the new branch" ? It's been pretty simple for the 14 years

Re: DBD::mysql path forward

Patrick and Pali, each of you please respond to the lists to confirm that what I say below is what you also understand is the primary plan, and if not, then say why not; in prior discussion I recall you agreed with it. Assuming they agree, the concerns of Night Light and those he is speaking

Re: DBD::mysql path forward

I think we have not decided how we should fix the unicode issues. Previously in this thread, it seemed to be pali and Dan Book had other ideas about this than most others. I wrote on this topic earlier to pali: On Wed, Sep 13, 2017 at 9:21 AM, wrote: > I would suggest to

Re: DBD::mysql path forward

My understanding from the last discussion on this matter is that it was agreed DBD::mysql would be forked such that the existing DBD::mysql name would be frozen at 4.041/3 indefinitely and that the 4.042 changes plus any further feature development would take place under a new name such as

Re: DBD::mysql path forward

For the reason of "silence": I've spoken to other users to hear that they have passively withdrawn from this discussion as they are not motivated to be part of a release where concerns about backwards compatibility are ignored. One of the users wrote earlier (replace the word "sector" with

Re: DBD::mysql path forward

Pali, I totally understand - timing timing - I started a new job and found out I had to prepare to talk about MySQL/Kubernetes at kubecon, so I apologize, and didn't plan it that way. Let me re-review those emails and give a decision, of course, your decision as well. As far as maintainer,

Re: DBD::mysql path forward

Pali, I have given you co-maintainership to DBD::mysql and permissions on the repo - let's go ahead and move forward. Thank you, Patrick On 11/3/17 11:17 AM, Patrick M. Galbraith wrote: Pali, Sorry, I wanted to give it time for people, plus have been very busy. I'm ready, just let me

Re: DBD::mysql path forward

Dan, I think get the original work Pali did (I need to get the master-new he references below in) and also I need to figure out what it will inevitably mean for distribution packages. And test, and test. I need to also find the emails of people who had a problem last time and have a plan to

Re: DBD::mysql path forward

How can we proceed from here? -Dan On Mon, Sep 18, 2017 at 1:17 PM, Patrick M. Galbraith wrote: > Pali, > > Great! Now we can start moving forward. > > Sorry if my responses have been intermittent - first week at new job. > > Regards, > > Patrick > On 9/16/17 4:35 AM,

Re: DBD::mysql path forward

On Tuesday 26 September 2017 14:20:33 Night Light wrote: > That's a nifty function. Good to know that it can be reversed. UTF-8 encode is a function which for any number from the range 0..1114111 assign unique sequence of the numbers 0..255. Therefore this function has a well defined inverse -

Re: DBD::mysql path forward

On Tuesday 26 September 2017 14:20:33 Night Light wrote: > I noticed that it was mentioned in DBD::mysql # 117 that DBD::mysql does > know that a column in a returned resultset is a BLOB. For returned values via MySQL protocol, there are two different and independent things: SQL type and

Re: DBD::mysql path forward

On 27 September 2017 at 16:16, wrote: > On Tuesday 26 September 2017 14:20:33 Night Light wrote: >> That's a nifty function. Good to know that it can be reversed. > > UTF-8 encode is a function which for any number from the range > 0..1114111 assign unique sequence of the numbers

Re: DBD::mysql path forward

The corruption is caused by the fact that the data type of a BLOB can not be recognized and is therefore UTF8 encoded like a string before being sent to MySQL. I'd like to propose the introduction of an attribute to ensure correct UTF8 encoding while maintaining backwards compatibility. Manual

Re: DBD::mysql path forward

On 19 September 2017 at 14:46, Night Light wrote: > Dear Perl gurus, > > This is my first post. I'm using Perl with great joy, and I'd like to > express my gratitude for all you are doing to keep Perl stable and fun to > use. > > I'd like to ask to object to re-releasing

Re: DBD::mysql path forward

On 26 September 2017 at 12:15, Night Light wrote: > The corruption is caused by the fact that the data type of a BLOB can not be > recognized and is therefore UTF8 encoded like a string before being sent to > MySQL. Which means it can be fixed. And in a sane scenario will

Re: DBD::mysql path forward

Hello, may I ask how this situation differs from upgrading DBD::Pg to version 3.3.0 or DBD::SQLite to version 1.43_04? What you are writing there basically affects also DBD::SQLite... And version 1.43_04 was already released... On Tuesday 19 September 2017 14:46:09 Night Light wrote: > Dear

Re: DBD::mysql path forward

> On Sep 19, 2017, at 10:10 AM, Darren Duncan wrote: > > What Night Light's post says to me is that there is high risk of causing data > corruption if any changes are made under the DBD::mysql name where DBD::mysql > has not been exhaustively tested to guarantee that

Re: DBD::mysql path forward

Dear Perl gurus, This is my first post. I'm using Perl with great joy, and I'd like to express my gratitude for all you are doing to keep Perl stable and fun to use. I'd like to ask to object to re-releasing this version and discuss on how to make 4.043 backwards compatible instead. This change

Re: DBD::mysql path forward

What Night Light's post says to me is that there is high risk of causing data corruption if any changes are made under the DBD::mysql name where DBD::mysql has not been exhaustively tested to guarantee that its behavior is backwards compatible. This makes a stronger case to me that the

Re: DBD::mysql path forward

Pali, Great! Now we can start moving forward. Sorry if my responses have been intermittent - first week at new job. Regards, Patrick On 9/16/17 4:35 AM, p...@cpan.org wrote: On Friday 15 September 2017 04:06:57 Patrick M. Galbraith wrote: On 9/13/17 9:31 AM, p...@cpan.org wrote: On

Re: DBD::mysql path forward

On Friday 15 September 2017 04:06:57 Patrick M. Galbraith wrote: > On 9/13/17 9:31 AM, p...@cpan.org wrote: > > On Tuesday 12 September 2017 11:32:36 Darren Duncan wrote: > >> On 2017-09-12 11:05 AM, p...@cpan.org wrote: > >>> On Tuesday 12 September 2017 19:00:59 Darren Duncan wrote: > I

Re: DBD::mysql path forward

Hi Paul! (long time!) we need to make sure we have these cases accounted for and test coverage. regards, Patrick On 9/14/17 9:24 PM, Paul DuBois wrote: On Sep 14, 2017, at 1:44 AM, p...@cpan.org wrote: MySQL server and its databases has some limitations, so reflect it: * it does not

Re: DBD::mysql path forward

On 9/13/17 9:31 AM, p...@cpan.org wrote: On Tuesday 12 September 2017 11:32:36 Darren Duncan wrote: On 2017-09-12 11:05 AM, p...@cpan.org wrote: On Tuesday 12 September 2017 19:00:59 Darren Duncan wrote: I strongly recommend that another thing happen, which is re-versioning DBD::mysql to

Re: DBD::mysql path forward

> On Sep 14, 2017, at 1:44 AM, p...@cpan.org wrote: > > MySQL server and its databases has some limitations, so reflect it: > > * it does not provide information if placeholder is TEXT, VARCHAR, VARBINARY > or BLOB > * placeholder's bind value does not have to point to column, it can be also

Re: DBD::mysql path forward

On 2017-09-14 3:01 AM, H.Merijn Brand wrote: On Thu, 14 Sep 2017 09:44:54 +0200, p...@cpan.org wrote: BYTE/BLOB/TEXT tests require three types of data • Pure ASCII • Correct UTF-8 (with complex combinations) subtest: Correct UTF-8 TEXT with only code points in range U+00 .. U+7F (ASCII

Re: DBD::mysql path forward

On Thu, 14 Sep 2017 09:44:54 +0200, p...@cpan.org wrote: > > BYTE/BLOB/TEXT tests require three types of data > > > > • Pure ASCII > > • Correct UTF-8 (with complex combinations) > > subtest: Correct UTF-8 TEXT with only code points in range U+00 .. U+7F > (ASCII subset) > subtest: Correct

Re: DBD::mysql path forward

On Thursday 14 September 2017 08:21:42 H.Merijn Brand wrote: > On Wed, 13 Sep 2017 13:27:58 -0700, Darren Duncan > wrote: > > > On 2017-09-13 12:58 PM, Dan Book wrote: > > > On Wed, Sep 13, 2017 at 3:53 AM, Peter Rabbitson wrote: > > > > > > On 09/12/2017 07:12 PM,

Re: DBD::mysql path forward

On Wed, 13 Sep 2017 13:27:58 -0700, Darren Duncan wrote: > On 2017-09-13 12:58 PM, Dan Book wrote: > > On Wed, Sep 13, 2017 at 3:53 AM, Peter Rabbitson wrote: > > > > On 09/12/2017 07:12 PM, p...@cpan.org wrote: > > And here is promised script: > > > > >

Re: DBD::mysql path forward

On 09/12/2017 07:12 PM, p...@cpan.org wrote: On Tuesday 12 September 2017 12:27:25 p...@cpan.org wrote: To prove fact that other DBI drivers (e.g. Pg or SQLite) had fixed similar/same UTF-8 issue as MySQL has and behave Perl-correctly, I would provide test cases so you would see difference

Re: DBD::mysql path forward

On 09/13/2017 09:58 PM, Dan Book wrote: On Wed, Sep 13, 2017 at 3:53 AM, Peter Rabbitson > wrote: On 09/12/2017 07:12 PM, p...@cpan.org wrote: On Tuesday 12 September 2017 12:27:25 p...@cpan.org

Re: DBD::mysql path forward

On 2017-09-13 12:58 PM, Dan Book wrote: On Wed, Sep 13, 2017 at 3:53 AM, Peter Rabbitson wrote: On 09/12/2017 07:12 PM, p...@cpan.org wrote: And here is promised script: The script side-steps showcasing the treatment of BLOB/BYTEA columns, which was one of the main (

Re: DBD::mysql path forward

On Wed, Sep 13, 2017 at 3:53 AM, Peter Rabbitson wrote: > On 09/12/2017 07:12 PM, p...@cpan.org wrote: > >> On Tuesday 12 September 2017 12:27:25 p...@cpan.org wrote: >> >>> To prove fact that other DBI drivers (e.g. Pg or SQLite) had fixed >>> similar/same UTF-8 issue as MySQL

Re: DBD::mysql path forward

On 2017-09-13 6:31 AM, p...@cpan.org wrote: On Tuesday 12 September 2017 11:32:36 Darren Duncan wrote: Regardless, following point 2, mandate that all Git pull requests are made against the new 5.x master; the 4.x legacy branch would have no commits except minimal back-porting. New pull

Re: DBD::mysql path forward

On Tuesday 12 September 2017 11:32:36 Darren Duncan wrote: > On 2017-09-12 11:05 AM, p...@cpan.org wrote: > >On Tuesday 12 September 2017 19:00:59 Darren Duncan wrote: > >>I strongly recommend that another thing happen, which is > >>re-versioning DBD::mysql to 5.0. > >> > >>1. From now on,

Re: DBD::mysql path forward

I would suggest to communicate with all people behind cpan modules which uses mysql_enable_utf8. https://grep.metacpan.org/search?size=20=mysql_enable_utf8== They should know if their modules are expecting old broken or behavior of DBD::mysql or not. I would expect that are modules which needs

Re: DBD::mysql path forward

Patrick M. Galbraith wrote: Hi all, After talking to Pali and looking at how other drivers have handled the issue, the best way forward will be to deal with solving the UTF-8 issue correctly as was attempted in May. This will be a problem for some, but only due to having to been

Re: DBD::mysql path forward

On 2017-09-12 6:45 PM, Patrick M. Galbraith wrote: Darren, I agree with this as well, with the exception of 4 and 5, keeping 5.0 "pure" to the new way of doing things. I very much agree, pure is best. I only suggested 4 and 5 as half-hearted options because I knew some projects in our

Re: DBD::mysql path forward

Darren, I agree with this as well, with the exception of 4 and 5, keeping 5.0 "pure" to the new way of doing things. For releases, I think I want to understand what this will mean. Sooner or later, a release shows up in as a distribution package, installed on the OS, and I want to know what

Re: DBD::mysql path forward

On 13/09/2017 03:00, Darren Duncan wrote: > 1. From now on, DBD::mysql versions 4.x would essentially be frozen at > 4.041/4.043. They would expressly never receive any breaking changes (but > see point 3) and in particular no Unicode handling changes. They would > expressly never receive

Re: DBD::mysql path forward

On 2017-09-12 11:05 AM, p...@cpan.org wrote: On Tuesday 12 September 2017 19:00:59 Darren Duncan wrote: I strongly recommend that another thing happen, which is re-versioning DBD::mysql to 5.0. 1. From now on, DBD::mysql versions 4.x would essentially be frozen at 4.041/4.043. 2. From now on,

Re: DBD::mysql path forward

On Tuesday 12 September 2017 19:00:59 Darren Duncan wrote: > On 2017-09-12 8:54 AM, Dan Book wrote: > > On Tue, Sep 12, 2017 at 11:04 AM, Patrick M. Galbraith wrote: > > Pali, > > Yes, I agree, we'll have to create a fork pre revert and stop > > accepting PRs How might we allow people

Re: DBD::mysql path forward

On Tuesday 12 September 2017 12:27:25 p...@cpan.org wrote: > To prove fact that other DBI drivers (e.g. Pg or SQLite) had fixed > similar/same UTF-8 issue as MySQL has and behave Perl-correctly, I > would provide test cases so you would see difference between Pg, > SQLite and mysql DBI drivers.

Re: DBD::mysql path forward

On 2017-09-12 8:54 AM, Dan Book wrote: On Tue, Sep 12, 2017 at 11:04 AM, Patrick M. Galbraith wrote: Pali, Yes, I agree, we'll have to create a fork pre revert and stop accepting PRs How might we allow people time to test the fixes to give them time? Just have them use the fork,

Re: DBD::mysql path forward

Another option is to revert that "big revert commit" in git and continue development. Then people would be able to create pull request without problem... Just need to be sure that new normal release would not be put to cpan. But it would be possible to put beta/engineering releases like it was

Re: DBD::mysql path forward

On Tue, Sep 12, 2017 at 11:54 AM, Dan Book wrote: > On Tue, Sep 12, 2017 at 11:04 AM, Patrick M. Galbraith > wrote: > >> Pali, >> >> Yes, I agree, we'll have to create a fork pre revert and stop accepting >> PRs >> >> How might we allow people time to test the

Re: DBD::mysql path forward

On Tue, Sep 12, 2017 at 11:04 AM, Patrick M. Galbraith wrote: > Pali, > > Yes, I agree, we'll have to create a fork pre revert and stop accepting PRs > > How might we allow people time to test the fixes to give them time? Just > have them use the fork, I would assume? > > Regards,

Re: DBD::mysql path forward

Pali, Yes, I agree, we'll have to create a fork pre revert and stop accepting PRs How might we allow people time to test the fixes to give them time? Just have them use the fork, I would assume? Regards, Patrick On 9/12/17 6:27 AM, p...@cpan.org wrote: On Tuesday 12 September 2017

Re: DBD::mysql path forward

On Tuesday 12 September 2017 05:40:31 Patrick M. Galbraith wrote: > Hi all, > > After talking to Pali and looking at how other drivers have handled the > issue, the best way forward will be to deal with solving the UTF-8 issue > correctly as was attempted in May. This will be a problem for some,