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 through with security patches are also ignored. The code is simply bundled and presented as 'take it or leave it'.
The result is the project being stalled because that apart from the fact that the code never will pass UAT (as it changes the interface and causes database corruption) there is one fact of reality: you are simply the only person that is actually willing to change the driver code (and I would like to thank you for that). In other words: there are currently no alternative resources available that can assist overcoming these hurdles. With this background I ask/asked if there is at least one other person willing to review the driver code changes (248 changed lines in dbdimp.c) to make sure that the judgement that forking is inevitable and is not based on the opinion of one person but shared among others. I believe your word and expect that the outcome is that forking is indeed necessary, but this step has another advantage which is that somebody else also understands the code which will help ensuring that DBD::mysql can be maintained and remain stable. Kind Regards, Night Light On Fri, Nov 10, 2017 at 9:34 AM, <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) > >
