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, <p...@cpan.org> wrote: > I would suggest to communicate with all people behind cpan modules which > uses 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 > correct behavior as not all perl people expect such bugs... > > They can update their modules to be compatible with both old buggy > behavior and new correct. Months ago I wrote update for DBD::mysql POD > documentation which mention example how to achieve it: I don't think this is a good idea. There is much more code using DBD::mysql than what you see on CPAN. If we are going to introduce changes in behavior, they should really be opt-in and not opt-out. Because otherwise it can corrupt peoples data and we should not want that. > Meanwhile DBD::mysql can try to play with "conflicts" relationship in > META.json to prevent installing one of the above cpan module which > depends on broken DBD::mysql until maintainer of that module fixes it. > > https://metacpan.org/pod/CPAN::Meta::Spec#Prereq-Spec > > I have never uses "conflicts" in META.json, so I do not know if it is > working correctly in all cpan clients, but according to documentation it > is a way how to achieve that users would not upgrade DBD::mysql to new > version if they have installed another module which needs old > DBD::mysql. Please understand that this is not a CPAN-only world. Many people install DBD::mysql using their linux package managers, especially for server installations of software. And some software which uses DBD::mysql (for instance OTRS, or Bugzilla) is typically not installed from CPAN. Of course the same goes for peoples internal systems. And that is assuming the 'conflicts' in META.json would actually work as expected. To me, the only real option is to make a new option in DBD::mysql; mysql_enable_proper_unicode or the like which you would knowingly set in your application code, which will expose the new behaviour. I understand this is difficult, but I really think it's the only way. If in the short term this is not feasible, it *could* be possible, in my eyes, to release a DBD::mysql2 or similar that does *correct* behaviour. Also in that case this is something the application developer should set explicitly in his connection string. This DBD::mysql2 or similar could live in another git repository, but preferably in the same repo, and even in the same CPAN distribution as DBD::mysql, and eventually the goal should be that they re-unite and using DBD::mysql2 would really be the same as to use the 'mysql_enable_proper_unicode' option in DBD::mysql. -- Michiel On Tue, Nov 7, 2017 at 7:41 PM, Darren Duncan <dar...@darrenduncan.net> wrote: > 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 > DBD::mysql2 version 5.0. > > So those people using "DBD::mysql" would not experience any changes in > behavior from what they were used to and BLOB etc should not break. Whereas > people that want the Unicode fixes and other features would use the > DBD::mysql2 and fix their code to be compatible with its breaking changes. > > I thought this was settled, and takes care of your concerns, so it was just > a matter of "make it so". > > (Anyone replying to this message/thread, please do NOT include my personal > email address as an explicit recipient, only send it to the list addresses, > I will get those.) > > -- Darren Duncan > > > On 2017-11-07 3:41 AM, Night Light wrote: >> >> 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 "release"): >> >> "When you're dealing with software that's purpose in life is to not >> corrupt >> data, and have data there tomorrow, you go out of your way not to break >> that >> promise. There's no point in being involved in this sector if you don't >> care to >> deliver on that promise." >> >> Re-releasing the 4.042 changes will break the contract of a long-standing >> interface and corrupt all BLOB data when using "do()". These changes do >> therefore more harm than good. >> Putting these utf8 changes in the freezer until a suggestion is made that >> will >> add the functionality instead of replacing it is not a sin. The PG driver >> has >> for instance also a similar issue open without plans to fix it anytime >> soon. >> https://rt.cpan.org/Public/Bug/Display.html?id=122991 >> >> What is your objection against using the current 4.043 branch and work on >> outstanding fixes, do a pre-release, a period of time for people to >> test/try >> out, then release?
