# Remove ext/mysql from trunk? (was: Re: Remove sqlite2 from trunk) - Thread: https://externals.io/message/48835 - Original archive: https://news-web.php.net/php.internals/48835 - Started by Patrick ALLAERT on 2010-06-19T09:33:45+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #48835 — Patrick ALLAERT — 2010-06-19T09:33:45+00:00 URL: https://externals.io/message/48835#48835 2010/6/19 Ulf Wendel : > Johannes Schlüter schrieb: > > […] > > 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 --- ## #48836 — Sebastian Bergmann — 2010-06-19T10:45:39+00:00 URL: https://externals.io/message/48835#48836 · In reply to: #48835 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/ --- ## #48837 — Johannes.Schlueter@Sun.COM — 2010-06-19T11:00:19+00:00 URL: https://externals.io/message/48835#48837 · In reply to: #48836 > Am 19.06.2010 11:33, schrieb Patrick ALLAERT: > > […] > > 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 --- ## #48838 — Sebastian Bergmann — 2010-06-19T11:40:23+00:00 URL: https://externals.io/message/48835#48838 · In reply to: #48837 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/ --- ## #48847 — Ulf Wendel — 2010-06-20T10:01:09+00:00 URL: https://externals.io/message/48835#48847 · In reply to: #48837 Johannes Schlüter schrieb: > > > […] > > ... 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 --- ## #48849 — Lukas Kahwe Smith — 2010-06-20T11:00:07+00:00 URL: https://externals.io/message/48835#48849 · In reply to: #48847 > Johannes Schlüter schrieb: > > […] > > 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