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. Calling perlapi functions may change this internal state under some circumstances and IIRC perl (itself) can change. Therefore it is not safe to touching code around. Fixing Unicode support needs to totally replace this code.
Night Light wrote that enable_utf8=0 does no encoding of input and this is not truth. It is also root of all problems and applications which misuse it. Also we have no idea what else applications misuse. And because we were not already able to detect it in testing period, I really doubt that we would be able to do it in future... On Friday 10 November 2017 09:34:19 p...@cpan.org wrote: > 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 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 developer who finds it > > hard or probably impossible to implement. > > > > Can before forking at least a second person with C knowledge open dbdimp.c > > and measure if it is indeed unfeasible to make the module backward > > compatible by adding an option as suggested? > > > > Michiel, do you know C? Can you do that 5-minute check? > > > > The breaking is due to the fact that the prepared SQL statement and the > > bound parameters will be apart from what is returned from MySQL is encoded > > as well. > > The mysql_enable_utf8/mysql_enable_utf8mb4 flags already arrange logic to > > set if utf8 encoding/decoding should be done or not. > > I'm not a C expert but this is what I find in dbdimp.c of 4.042 about it: > > > > dbd_st_prepare_sv function: > > bool enable_utf8 = (imp_dbh->enable_utf8 || imp_dbh->enable_utf8mb4); > > get_statement(aTHX_ statement_sv, enable_utf8, &statement, &statement_len); > > > > dbd_bind_ph function: > > bool enable_utf8 = (imp_dbh->enable_utf8 || imp_dbh->enable_utf8mb4); > > bind_param(&imp_sth->params[idx], value, sql_type, idx+1, enable_utf8); > > > > > > Would changing that into the following make the module backwards compatible? > > bool enable_utf8 = (imp_dbh->enable_utf8 == 2 || imp_dbh->enable_utf8mb4 == > > 2); > > > > enable_utf8 0 = no encoding of input and only decoding of output > > enable_utf8 1 = decode only output (4.043 mode) > > enable_utf8 2 = encoded input and decode output (4.042 mode) > > > > On Fri, Nov 10, 2017 at 8:37 AM, Darren Duncan <dar...@darrenduncan.net> > > wrote: > > > > > 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 PM, Michiel Beijen wrote: > > > > > >> On Fri, Nov 10, 2017 at 7:16 AM, Darren Duncan <dar...@darrenduncan.net> > > >> wrote: > > >> > > >>> I agree with everything Dan said here. Its what I proposed, in fewer > > >>> words. > > >>> Do all new development under a new name, including all of Pali's work, > > >>> and > > >>> leave the current name for a product with no further effort applied to > > >>> develop it. -- Darren Duncan > > >>> > > >> > > >> This is NOT an option to me - it simply can't because the world moves > > >> forward and because of bitrot. The 'old' version - the version that > > >> works for most people, the current version of DBD::mysql, the one > > >> which would then receive no more maintenance as it is no longer > > >> compiles with the latest version of libmysqlclient and it does not > > >> compile with libmariadb. This will only get worse in the future. > > >> > > >> 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 testing on many different lib/db options, memory > > >> leaks and so on, and make a new release so we can be on the move > > >> again. > > >> > > >> If possible I'd want to add back the *breaking* unicode changes that > > >> were introduced but they should be either in a separate namespace OR > > >> under a specific configuration option. > > >> Currently this whole thing has cost us loosing MONTHS of progress and > > >> then MONTHS of nothing and that is simply not good. > > >> > > >> Patrick: let me know if you're OK with this and then let's get start > > >> again! > > >> > > >
