Re: DBD::mysql path forward

[Paul DuBois]

> 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 its behavior is backwards 
> compatible.
> 
> This makes a stronger case to me that the DBD::mysql Git master (that which 
> includes the 4.042 changes and any other default breaking changes) should 
> rename the Perl driver package name, I suggest DBD::mysql2 version 5.0, and 
> that any changes not guaranteed backwards compatible for whatever reason go 
> there.
> 
> If the Git legacy maintenance branch 4.041/3 can have careful security 
> patches applied that don't require any changes to user code to prevent 
> breakage, it gets them, and otherwise only DBD::mysql2 gets any changes.
> 
> By doing what I said, we can be guaranteed that users with no control over 
> how DBD::mysql gets upgraded for them will introduce corruption simply for 
> upgrading.

I don't think we want to guarantee that they will introduce corruption simply 
for upgrading. :-)

> 
> -- Darren Duncan
> 
> On 2017-09-19 5:46 AM, 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 this version and discuss on how to
>> make 4.043 backwards compatible instead.
>> This change will with 100% certainty corrupt all BLOB data written to the
>> database when the developer did not read the release notes before applying 
>> the
>> latest version of DBD::mysql (and changed its code consequently).
>> Knowing that sysadmins have the habit of not always reading the release 
>> notes of
>> each updated package the likelihood that this will happen will therefore 
>> high.
>> I myself wasn't even shown the release notes as it was a dependency of an
>> updated package that I applied.
>> The exposure of this change is big as DBD::mysql affects multiple 
>> applications
>> and many user bases.
>> I believe deliberately introducing industry wide database corruption is
>> something that will significantly harm peoples confidence in using Perl.
>> I believe that not providing backwards compatibility is not in line with the
>> Perl policy that has been carefully put together by the community to maintain
>> the quality of Perl as it is today.
>> http://perldoc.perl.org/perlpolicy.html#BACKWARD-COMPATIBILITY-AND-DEPRECATION
>> 
>> I therefore believe the only solution is an upgrade that is by default 
>> backwards
>> compatible, and where it is the user who decides when to start UTF8 encode 
>> the
>> input values of a SQL request instead.
>> If it is too time consuming or too difficult it should be considered to park 
>> the
>> UTF8-encoding "fix" and release a version with the security fix first.
>> 
>> I have the following objections against this release:
>> 
>> 1. the upgrade will corrupt more records than it fixes (it does more harm 
>> than good)
>> 2. the reason given for not providing backward compatibility ("because it was
>> hard to implement") is not plausible given the level of unwanted side 
>> effects.
>>   This especially knowing that there is already a mechanism in place to 
>> signal
>> if its wants UTF8 encoding or not (mysql_enable_utf8/mysql_enable_utf8mb4).
>> 3. it costs more resources to coordinate/discuss a "way forward" or options 
>> than
>> to implement a solution that addresses backwards compatibility
>> 4. it is unreasonable to ask for changing existing source knowing that 
>> depending
>> modules may not be actively maintained or proprietary
>>   It can be argued that such module should always be maintained but it does 
>> not
>> change the fact that a good running Perl program becomes unusable
>> 5. it does not inform the user that after upgrading existing code will start
>> write corrupt BLOB records
>> 6. it does not inform the user about the fact that a code review of all 
>> existing
>> code is necessary, and how it needs to be changed and tested
>> 7. it does not give the user the option to decide how the BLOB's should be
>> stored/encoded (opt in)
>> 8. it does not provide backwards compatibility
>>   By doing so it does not respect the Perl policy that has been carefully put
>> together by the community to maintain the quality of Perl as it is today.
>>   
>> http://perldoc.perl.org/perlpolicy.html#BACKWARD-COMPATIBILITY-AND-DEPRECATION
>> 9. it blocks users from using DBD::mysql upgrades as long as they have not
>> rewritten their existing code
>> 10. not all users from DBD::mysql can be warned beforehand about the side
>> effects as it is not known which private parties have code that use 
>> DBD::mysql
>> 12. I believe development will go faster when support for backwards
>> compatibility is addressed
>> 13. having to write 1 extra 

Re: DBD::mysql path forward

[Paul DuBois]

> 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 
> SQL function
>  --> for caller/user all placeholders are equivalent and caller itself
>  needs to know how to treat bind variable and needs to specify if
>  it is TEXT or BLOB
> 
> * VARBINARY is right padded with 0x00
>  --> there is no difference between binary "\x01\x02\x00" and "\x01\x02"

BINARY is padded (for storage), VARBINARY is not.

https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html

Re: State of DBD::mysql maintenance

[Paul DuBois]

On Jun 27, 2013, at 8:16 PM, Lyle wrote:

 On 27/06/2013 22:22, Tim Bunce wrote:
 If you're a DBD::mysql user and care about the future of the code, please 
 help out.
 
 I felt the same when I came across this during my research. I didn't have a 
 great deal of luck in my initial efforts to reach out. It seems like 
 Oracle/MySQL have lost a lot of interested in DBD::mysql (hence my post about 
 this a couple of months back).

Wait.

That thread was about your belief that Oracle was trying to distance itself 
from DBD::mysql or discourage its development. Which it is not. It's simply 
that DBD::mysql is not an Oracle product. Oracle is not responsible to fix 
DBD::mysql bugs.

That said, if your next statement is correct, that'd be great.

 However, it does appear that some activity has come back. I'm not sure if 
 anyone looked at my patch, but I have since realised that there was a lot 
 more amiss. DBD::mysql really needs to be updated for proper MySQL *5* 
 support.
 
 I was talking to Peter about extra hacking sessions at our last Perl meet. 
 I'll make sure this is on the agenda.

Good, thanks.

 
 
 Lyle
 

Re: DBD::mysql - bit worrying

[Paul DuBois]

On Apr 18, 2013, at 12:07 PM, Patrick Galbraith wrote:

 Lyle,
 
 To be certain, they don't wish to kill DBD::mysql. They are really trying 
 to define what Oracle supports and what they do not. The were very helpful in 
 painstakingly migrating the bugs from their system manually to RT. Albeit, I 
 have my work cut out for me now :)

I'm not an official spokesman for Oracle, although I do work for them.

I am unaware of any effort against DBD::mysql. Nor has Oracle made any effort 
to dissuade me from writing about DBD::mysql, e.g., at 
http://www.kitebird.com/mysql-book/. (You can view that URL as a shameless plug 
or just evidence in support of the preceding claims, your choice. :-))

 
 Regards,
 
 Patrick
 
 On Apr 11, 2013, at 8:28 PM, Lyle webmas...@cosmicperl.com wrote:
 
 On 12/04/2013 00:58, Darren Duncan wrote:
 On 2013.04.11 4:37 PM, Lyle wrote:
 Hmm... Got a reply to my bug report and it's a bit worrying:
 http://bugs.mysql.com/bug.php?id=68266
 
 Seems like MySQL don't want to directly support DBD::mysql any more. 
 Whether you
 like mysql or not, that's a heavily used DBD.
 
 I'm not aware that DBD::mysql was ever supported through the general MySQL 
 bug reporter, and I understood it was a separate project.
 
 It most certainly was, for example:
 http://bugs.mysql.com/bug.php?id=20153
 
 The DBD::mysql docs still tell you to report bugs there. Even I was able to 
 submit a bug to their DBD::mysql category just last February, they've only 
 just removed it from the bug reporter.
 
 I think Patrick Galbraith is the person you should ask about this matter, 
 as Patrick has been the one releasing DBD::mysql on CPAN for many years, a 
 full decade at this point.
 
 I've just joined the p...@lists.mysql.com mailing list. It'll be interesting 
 to see if that list stays or gets removed as well.
 
 
 Lyle
 
 
 -- Darren Duncan
 
 
 
 

Re: Spelling

[Paul DuBois]

On Jun 8, 2010, at 7:05 AM, H.Merijn Brand wrote:

 isn't it through in English?
 
 yes it is even in US English  it is through
 
 But Tim already spoke up: he likes thru

One thing to consider for readers whose English
is not that good is that they are probably more
likely to recognize through than thru.

Re: case sensitivity

[Paul DuBois]

I found out last week that MySQL is even worse, as it prohibits the  
use

of a space before a paren in aggregate functions. But that is not on
topic here.


True, though I believe there's a config option to control that
(a trade-off with some other feature that I don't now recall).



IGNORE_SPACE

http://dev.mysql.com/doc/refman/5.1/en/function-resolution.html

Re: DBD::mysql 3.0003 and 3.0003_1 released

[Paul DuBois]

On 5/6/06 11:54, Patrick Galbraith [EMAIL PROTECTED] wrote:

 Dear DBD::mysql users,
 
 DBD::mysql version 3.0003 (stable, production) and 3.0003_1 (dev) have
 been released!
 
 Version 3.0003 is the production version with server-side prepare
 statements turned off by default, and 3.0003_1 is the development
 version with server-side prepare statements turned on by default.
 
 The changes in 3.0003, as in the changelog, are:
 
 * Fixed bug where if mysql_server_prepare is set and a prepare
 fails, only a warning is issued and no error text is
 available (Thanks Martin Evans!)
   * Added support for ParamValues and associated test (Martin Evans)
   * Removed declaration of int num_fields outside a block which
 was causing compilation error with some C compilers.
   * Fix to typo in Makefile.PL (Martin Evans)
   * Added mysql_stmt_reset for when mysql_stmt_execute fails
   * Added test for mysql_stmt_execute bug (Martin Evans)
   * Fixed syntax for create table ENGINE=InnoDB instead of type=innobase
   * Removed tests for old driver emulation
 
 Note: to turn on server-side prepared statements, simply append
 ;mysql_server_prepare to the connect string or via the driver handle.
 Please refer to documentation for further details.

Can you append =0 or =1 to indicate explicitly that you want this turned off
or on?

Re: DBD::mysql 3.000 Released

[Paul DuBois]

At 14:44 +0200 7/1/05, Jochen Wiedmann wrote:

On 7/1/05, Steve Hay [EMAIL PROTECTED] wrote:


 to remove all mention of mysql_config which doesn't exist on Win32, and
 to sort out problems with long long, strncasecmp, etc.


As Patrick seems to be an employee of MySQL AB: A possibly better
solution would be to finally add mysql_config to the Windows
distributions. I can think of absolutely no reason, why this shouldn't
be possible or even difficult. And the advantages are quite obvious,
as the required libraries are varying, in particular on Windows.


I suppose one problem is that Windows doesn't have /bin/sh.  mysql_config
is a shell script.

--
Paul DuBois, MySQL Documentation Team
Madison, Wisconsin, USA
MySQL AB, www.mysql.com

Re: DBD::mysql 3.000 Released

[Paul DuBois]

At 22:37 +0200 7/6/05, Jochen Wiedmann wrote:

Paul DuBois wrote:


I suppose one problem is that Windows doesn't have /bin/sh.  mysql_config
is a shell script.


It does have cmd.exe. And for the purpose of mysql_config, that is 
way enough, isn't it?


I guess I wasn't aware that cmd.exe ran Bourne shell scripts.

--
Paul DuBois, MySQL Documentation Team
Madison, Wisconsin, USA
MySQL AB, www.mysql.com

Re: Savepoint support proposal

[Paul DuBois]

For MySQL, the savepoint info is:

- Available as of MySQL 4.1.1 for InnoDB transactions.
- Set a savepoint with:
  SAVEPOINT savepoint_name
- Rollback syntax accepts optional TO SAVEPOINT clause:
  ROLLBACK [TO SAVEPOINT savepoint_name]

Re: Maintaining DBD::mysql

[Paul DuBois]

At 11:50 -0500 3/24/03, Rudy Lippan wrote:
On Mon, 24 Mar 2003, Paul DuBois wrote:
  For table names (which can't contain '.' etc) the server will
 generate an error if and when appropriate.

 The exact rules for MySQL identifiers are:

 Database and table names cannot contain '\', '/', or '.' characters.
 Column and index names can.
What are the rules for escaping the quoting character?

create table `thisthat` (foo int);  -- confuses the mysql client.
create table asdf (`foo'bnar` int); -- confuses mysql client.
create table `asdf``asdf` (foo int); -- throws an error
The third one now works in 4.1 and creates a table named asdf`asdf.
The first two still fail.  I'll ask the devs about it.
And
mysql create table asdf (`foo\`bnar` int);
ERROR:
Unknown command '\`'.
ERROR 1064: You have an error in your SQL syntax.  Check the manual that
corresponds to your MySQL server version for the right syntax to use near
'bnar` int)
This still fails in 4.1, too.  I'll ask about it.

There have been several improvements made to the mysql parser in 4.1,
but you've identified some cases that still cause failure.

Re: Doc update for finish method

[Paul DuBois]

At 18:09 + 2/7/02, Tim Bunce wrote:
   =item Cping
***
*** 4181,4190 
   situations to allow the server to free up resources (such as sort
   buffers).

! When all the data has been fetched from a CSELECT statement, the driver
! should automatically call Cfinish for you. So you should Inot normally
! need to call it explicitly. (Adding calls to Cfinish after each
! fetch loop is a common mistake, don't do it, it can mask other problems.)

   Consider a query like:

--- 4181,4194 
   situations to allow the server to free up resources (such as sort
   buffers).

! When all the data has been fetched from a CSELECT statement, the
! driver should automatically call Cfinish for you. So you should
! Inot normally need to call it explicitly Iexcept when you know
! that you've not fetched all the data from a statement handle.
! The most common example is when you only want to fetch one row,
! but in that case the Cselectrow_* methods may be better anyway.
! Adding calls to Cfinish after each fetch loop is a common mistake,
! don't do it, it can mask genuine problems like uncaught fetch errors.

Granted that finish() after a loop is unnecessary().  But how does it
mask problems?

- If RaiseError is enabled, a fetch error raises an exception anyway.

- If you don't have RaiseError enabled, then you probably also would
   have an error test following the loop and before calling finish().

- If you don't have RaiseError enabled, and you have no test after
   the loop prior to the finish() call, you weren't going to find the
   error anyway.

What's an example where having finish() after the loop actually makes
a difference?  I'm trying to understand why is it a mistake, as
opposed to simply being superfluous?