deprecating ext/mysql

Am 10.07.2011 19:03, schrieb Philip Olson:

What this means to ext/mysql:

• Softly deprecate ext/mysql with education (docs) starting today
• Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
• Add pdo_mysql examples within the ext/mysql docs that mimic the current
  examples, but occasionally introduce features like prepared statements
• Focus energy on cleaning up the pdo_mysql and mysqli documentation
• Create a general "The MySQL situation" document that explains the situation

The PHP community has been recommending alternatives for several years now,
so hopefully this won't be a new concept or shock to most users

sounds reasonable and i would love to be not forced loading
"mysql.so" AND "mysqli.so" because some peopole are using
legacy code and unwilling to maintain their stuff

hi,

As I would love to kill ext/mysql, it is up to the mysql developers to decide.

Cheers,

Greetings PHP geeks,

Don't panic! This is not a proposal to add errors or remove this popular extension. Not yet anyway, because it's too popular to do that now.

The documentation team is discussing the database security situation, and educating users to move away from the commonly used ext/mysql extension is part of this.

This proposal only deals with education, and requests permission to officially convince people to stop using this old extension. This means:

 - Add notes that refer to it as deprecated
 - Recommend and link alternatives
 - Include examples of alternatives

There are two alternative extensions: pdo_mysql and mysqli, with PDO being the PHP way and main focus of future endeavors. Right? Please don't digress into the PDO v2 fiasco here.

What this means to ext/mysql:

 - Softly deprecate ext/mysql with education (docs) starting today
 - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
 - Add pdo_mysql examples within the ext/mysql docs that mimic the current
  examples, but occasionally introduce features like prepared statements
 - Focus energy on cleaning up the pdo_mysql and mysqli documentation
 - Create a general "The MySQL situation" document that explains the situation

The PHP community has been recommending alternatives for several years now, so hopefully this won't be a new concept or shock to most users.

Regards,
Philip

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Greetings PHP geeks,

Don't panic! This is not a proposal to add errors or remove this
popular extension. Not yet anyway, because it's too popular to do that
now.

The documentation team is discussing the database security situation,
and educating users to move away from the commonly used ext/mysql
extension is part of this.

This proposal only deals with education, and requests permission to
officially convince people to stop using this old extension. This
means:

• Add notes that refer to it as deprecated
• Recommend and link alternatives
• Include examples of alternatives

There are two alternative extensions: pdo_mysql and mysqli, with PDO
being the PHP way and main focus of future endeavors. Right? Please
don't digress into the PDO v2 fiasco here.

What this means to ext/mysql:

• Softly deprecate ext/mysql with education (docs) starting today
• Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
• Add pdo_mysql examples within the ext/mysql docs that mimic the
  current examples, but occasionally introduce features like prepared
  statements
• Focus energy on cleaning up the pdo_mysql and mysqli documentation
• Create a general "The MySQL situation" document that explains the
  situation

The PHP community has been recommending alternatives for several years
now, so hopefully this won't be a new concept or shock to most users.

Big +1 from me. We actually chose not to do a Mysql adapter in Zend_Db
primarily due to the security issues, but also due to the much more
advanced feature sets available in the mysqli and pdo/mysql adapters.

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

What this means to ext/mysql:

 - Softly deprecate ext/mysql with education (docs) starting today
 - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
 - Add pdo_mysql examples within the ext/mysql docs that mimic the current
  examples, but occasionally introduce features like prepared statements
 - Focus energy on cleaning up the pdo_mysql and mysqli documentation
 - Create a general "The MySQL situation" document that explains the situation

I'm hugely +1 on this. (Which won't be a shock to anyone on IRC.) It's
time to start softening the user base up for the idea that, one day,
ext/mysql will in fact go away, and probably won't be terribly
mourned.

Adam

What this means to ext/mysql:

• Softly deprecate ext/mysql with education (docs) starting today
• Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
• Add pdo_mysql examples within the ext/mysql docs that mimic the current
  examples, but occasionally introduce features like prepared statements
• Focus energy on cleaning up the pdo_mysql and mysqli documentation
• Create a general "The MySQL situation" document that explains the situation

+1, though check with the MySQL folk about whether they want mysqli or pdo_mysql to
be the recommended path.

Chris

--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/

Greetings PHP geeks,

Don't panic! This is not a proposal to add errors or remove this popular extension. Not yet anyway, because it's too popular to do that now.

The documentation team is discussing the database security situation, and educating users to move away from the commonly used ext/mysql extension is part of this.

This proposal only deals with education, and requests permission to officially convince people to stop using this old extension. This means:

• Add notes that refer to it as deprecated
• Recommend and link alternatives
• Include examples of alternatives

There are two alternative extensions: pdo_mysql and mysqli, with PDO being the PHP way and main focus of future endeavors. Right? Please don't digress into the PDO v2 fiasco here.

What this means to ext/mysql:

• Softly deprecate ext/mysql with education (docs) starting today
• Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
• Add pdo_mysql examples within the ext/mysql docs that mimic the current
  examples, but occasionally introduce features like prepared statements
• Focus energy on cleaning up the pdo_mysql and mysqli documentation
• Create a general "The MySQL situation" document that explains the situation

The PHP community has been recommending alternatives for several years now, so hopefully this won't be a new concept or shock to most users.

Regards,
Philip

A-frickin'-men! :-)

Just today I was talking to a new developer in #PHP in IRC who had code
with mysql_* calls in it. I don't know where he found them, but I told
him to put them back where he found them right away and use PDO
instead. That people are still learning ext/mysql in this day and age
is quite sad.

There's millions of lines of code out there we can't break yet, but we
can absolutely structure documentation so that we don't produce even
more PHP developers who mistakenly think that mysql_query() is a good idea.

+1

--Larry Garfield

Hi,

Greetings PHP geeks,

Don't panic! This is not a proposal to add errors or remove this
popular extension. Not yet anyway, because it's too popular to do that
now.

The documentation team is discussing the database security situation,
and educating users to move away from the commonly used ext/mysql
extension is part of this.

Moving away from ext/mysql is not only about security but also about
having access to all features of the MySQL database.

ext/mysql was built for MySQL 3.23 and only got very few additions since
then while mostly keeping compatibility with this old version which
makes the code a bit harder to maintain. From top of my head missing
features not support be ext/mysql include:
* Stored Procedures (can't handle multiple result sets)
* Prepared Statements
* Encryption (SSL)
* Compression
* Full Charset support
* ...
*

So moving away from ext/mysql is a good thing.

This proposal only deals with education, and requests permission to
officially convince people to stop using this old extension. This
means:

• Add notes that refer to it as deprecated
• Recommend and link alternatives
• Include examples of alternatives

+1

There are two alternative extensions: pdo_mysql and mysqli, with PDO
being the PHP way and main focus of future endeavors. Right? Please
don't digress into the PDO v2 fiasco here.

I'm not sure the current PDO is "the" alternative. We (= MySQL/ORACLE)
focus mostly on mysqli, that's the extension providing access to all
current and future features of MySQL. True, many features could be added
to PDO but there are two design decision in PDO which make this bad:

  * The parser used for identifying statement place holders is very
    basic, as it is implemented in PDO core, not the drivers, which
    leads to FRs like #54929 or the famous LIKE issue[1]
  * driver-specific functions are implemented by using __call()
    which means there is no good introspection mechanism to check
    whether a feature is available or not in the current setup.

Besides these two items there are every now and then reports on
PDO_mysql which in fact are caused by limitations in the PDO design
which can't be bypassed by the driver implementation.

A good abstraction layer would certainly be good for the language but
for now we (=MySQL/ORACLE) consider mysqli the preference.

What this means to ext/mysql:

• Softly deprecate ext/mysql with education (docs) starting today
• Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
• Add pdo_mysql examples within the ext/mysql docs that mimic the current
  examples, but occasionally introduce features like prepared statements
• Focus energy on cleaning up the pdo_mysql and mysqli documentation
• Create a general "The MySQL situation" document that explains the situation

I also want to point to http://forge.mysql.com/wiki/Converting_to_MySQLi
wich has a script once developed by Ulf and others to automatically
convert code from using ext/mysql to mysqli. I haven't tried it with
recent versions of PHP but should still work.

The PHP community has been recommending alternatives for several years
now, so hopefully this won't be a new concept or shock to most users.

:-)

johannes

[1] The LIKE case goes something like that:

<?php
$query = $pdo->prepare("SELECT id FROM table LIMT ?, ?");
$query->bindValue(1, $_GET["offset"]);
$query->bindValue(2, $_GET["limit"]);
$query->execute();
?>

So there's some pagination of a result set and the user can browse
through the result, looks quite ok, but the result is not a successful
query but an error

    1064 you have an error in oyur SQL sytax; check the manual that
    corresponds to your MySQK server version for the right syntax to
    use near ''1', '2''

Which is caused by PDO using PS emulation by default with MySQL (see
thread "Change Request: Make PDO default to not emulate prepared
statements for MySQL" from April/May 2011 on this list) and $_GET
containing strings while the parser is not context-aware. Of course this
can easily be fixed by explicitly binding using PDO::PARAM_INT.

--
Johannes Schlüter, ORACLE
MySQL Engineering - Connectors And Client Connectivity