Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48835
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        b=lkPVq7P8UcrU4QCtIMu2KxTYIpIUAvzQwBtWEa2LYjXulEmX22KGPKUKk2W6dP9IHO
         34e/rUDwCYeRViGrhH8mNy3HmjQh0c/3QtcCy7NLVwK6P7wq75w6sSBxxyJiyhW7Z5s9
         Dq7AlhZ/rUX0ypWreoH1dG9td9h5qXW260RLE=
MIME-Version: 1.0
Date: Sat, 19 Jun 2010 11:33:45 +0200
Message-ID: <AANLkTinIw8hRh5sCW9rAjKxcrZyvHGgdAeFXPVA72dC0@mail.gmail.com>
To: Ulf Wendel <ulf.wendel@phpdoc.de>
Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <Johannes.Schlueter@sun.com>, 
	Mike Robinson <mike@rile.ca>, Pierre Joye <pierre.php@gmail.com>, Derick Rethans <derick@php.net>, 
	Ilia Alshanetsky <ilia@prohost.org>, Adam Harvey <aharvey@php.net>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [PHP-DEV] Remove ext/mysql from trunk? (was: Re: [PHP-DEV] Remove 
	sqlite2 from trunk)
From: patrick.allaert@gmail.com (Patrick ALLAERT)

2010/6/19 Ulf Wendel <ulf.wendel@phpdoc.de>:
> Johannes Schl=C3=BCter schrieb:
>>
>> As I said before in this thread: Realistically we can't drop it. Too
>> many tutorials, books, applications, ... mention mysql_* and ignore the
>> limitations and issues the old mysql extension provides...
>
> True, true...
>
> One of the best things one can do is to bash very article, blog posting,
> mailinglist posting and in particular every recent book showing ext/mysql
> examples instead or either ext/mysqli or PDO_MySQL examples.
>
> Every now and then we get feature requests for ext/mysql through bug
> reports. The reporters often complain badly if we MySQL guys refuse to ad=
d
> the requested feature to ext/mysql ...
>
> Ulf

I understand and agree on most of the concerns by not
bundling/activating ext/mysql by default. Those are valuable
arguments.

The problem I would like to avoid in a couple of years is having a PHP
which will contain 4 different built-in MySQL API and 3 different
array/hash/map, or whatever, implementations.

My concerns are about:
QA: less code to maintain, fewer bugs
Doc, tutorials, books,...: by having multiple (built-in) ways to
achieve the same operation we end up with that many different
approach, this is confusing to (new) developers -> I've seen mysql_*()
functions in my book, but this new/shiny tutorial is using
mysqli_()... what's best? Interesting read:
http://stackoverflow.com/questions/2190737/what-is-difference-between-mysql=
-mysqli-and-pdo
Developers: by developing several corporate applications, they will
end up knowing the two API's because of the initial choice of early
developers. This is the opposite of standardization which is so
important to the corporate world, do they need to use a framework to
have the benefit of standardization?
Software vendor: at the commercial level, softwares needs to support a
database (MySQL), not a database *layer* (mysql/mysqli). Because of
the heterogeneity of installations, software needs to be able to
support both layers!
example: http://github.com/ezsystems/ezpublish/blob/master/lib/ezdb/classes=
/ezmysqldb.php
and http://github.com/ezsystems/ezpublish/blob/master/lib/ezdb/classes/ezmy=
sqlidb.php
If they don't, then you end up with a lot of threads about it (=3D time
which may be used for something more interesting):
http://www.google.com/search?q=3Dwordpress+mysql+mysqli

Moving ext/mysql to PECL is a "possible" solution, I'm not defending
this one despite all opposition.
I am only interested in the ultimate goal: "How can we favor the use
of ext/mysqli?".
What are the possible actions/alternatives?

Patrick