2010/6/19 Ulf Wendel ulf.wendel@phpdoc.de:
Johannes Schlüter 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 add
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/ezmysqlidb.php
If they don't, then you end up with a lot of threads about it (= time
which may be used for something more interesting):
http://www.google.com/search?q=wordpress+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
Am 19.06.2010 11:33, schrieb Patrick ALLAERT:
What are the possible actions/alternatives?
I think this was already mentioned: add a BC layer to ext/mysqli so
that the "new" extension supports the old mysql_* functions. This would
rid us off the old ext/mysql code without breaking code that relies on
it.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Am 19.06.2010 11:33, schrieb Patrick ALLAERT:
What are the possible actions/alternatives?
I think this was already mentioned: add a BC layer to ext/mysqli so
that the "new" extension supports the old mysql_* functions. This would
rid us off the old ext/mysql code without breaking code that relies on
it.
... while such a wrapper has about the same amount of code as the
classic mysql extension (... which is in most parts a simple wrapper
over library functions...) Or in other words: Such a wrapper doesn't
have real benefits.
What might be interesting is to write the wrapper in 100% PHP on top of
mysqli. that gives an easy migration path (include/auto_prepend that
lib) and makes the purpose clear ... (while there is one major
limitation with such an approach: The old mysql extension uses resources
whereas mysqli uses objects, so $conn = mysql_connect();
var_dump(is_resource($conn)); can't be emulated that way)
johannes
--
Johannes Schlüter
MySQL Engineering Connectors and Client Connectivity
Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht München: HRB161028 Geschäftsführer: Jürgen Kunz
Am 19.06.2010 13:00, schrieb Johannes Schlüter:
.... while such a wrapper has about the same amount of code as the
classic mysql extension (... which is in most parts a simple wrapper
over library functions...) Or in other words: Such a wrapper doesn't
have real benefits.
I see.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Johannes Schlüter schrieb:
Am 19.06.2010 11:33, schrieb Patrick ALLAERT:
What are the possible actions/alternatives?
I think this was already mentioned: add a BC layer to ext/mysqli so
that the "new" extension supports the old mysql_* functions. This would
rid us off the old ext/mysql code without breaking code that relies on
it.... while such a wrapper has about the same amount of code as the
classic mysql extension (... which is in most parts a simple wrapper
over library functions...) Or in other words: Such a wrapper doesn't
have real benefits.
And any wrapper which is there by default won't change anything. People
will continue to use the old API. You need to move the masses or create
facts by removing ext/mysql. The latter is quite crazy considering how
popular ext/mysql is. Its popularity is somewhat understandable: its old
and the API is very phpish in a classical non PJAVA sense.
One of the few things that could be done is adding a note to each and
every ext/mysql docs page stating that one shall use ext/mysqli instead
and give examples how to do it.
Ulf
Johannes Schlüter schrieb:
Am 19.06.2010 11:33, schrieb Patrick ALLAERT:
What are the possible actions/alternatives?
I think this was already mentioned: add a BC layer to ext/mysqli so
that the "new" extension supports the old mysql_* functions. This would
rid us off the old ext/mysql code without breaking code that relies on
it.
... while such a wrapper has about the same amount of code as the
classic mysql extension (... which is in most parts a simple wrapper
over library functions...) Or in other words: Such a wrapper doesn't
have real benefits.And any wrapper which is there by default won't change anything. People will continue to use the old API. You need to move the masses or create facts by removing ext/mysql. The latter is quite crazy considering how popular ext/mysql is. Its popularity is somewhat understandable: its old and the API is very phpish in a classical non PJAVA sense.
One of the few things that could be done is adding a note to each and every ext/mysql docs page stating that one shall use ext/mysqli instead and give examples how to do it.
well couldnt the compat layer be written in PHP? i think this will send a fairly clear message. finally IIRC there was a mysql->mysqli conversion script that could be prominently placed in the docs. and of course we can add deprecation notices.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org