Re: [PHP-DEV] deprecating ext/mysql
Hi, On Sun, 2011-07-10 at 10:03 -0700, Philip Olson wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] deprecating ext/mysql
Am 15.07.2011 14:46, schrieb Johannes Schlüter: 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) so far correct * Compression not true client_flags and MYSQL_CLIENT_COMPRESS exists sine nearly 10 years this is a feature which currently sucks with mysqlnd because it is not supported this time signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] deprecating ext/mysql
On Fri, 2011-07-15 at 14:56 +0200, Reindl Harald wrote: Am 15.07.2011 14:46, schrieb Johannes Schlüter: 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) so far correct * Compression not true client_flags and MYSQL_CLIENT_COMPRESS exists sine nearly 10 years Thanks for the corrections. this is a feature which currently sucks with mysqlnd because it is not supported this time compression support was added for mysqlnd with r291051 on 2009-11-20 09:12:14 +0100 which translates to 5.3.2, I think. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Add grisu3 strtod algorithm
Hi Internals, I want to propose the inclusion of Florian Loitschs (called grisu3) strtod algorithm. Essentially Florian found a new algorithm for string to double conversion and vice versa. According to micro benchmarks in PHP and experiences with the library in the haskell community, this can speed up heavy conversions like json_decode up to 20-30%. It is a backward compatible change as we will not change the underlying zend_strtod api. The proposed change is enabled with a flag and will be disabled by default. As no underlying API is affected and because it's disabled by default, I propose this change to be included in PHP 5.4. I'll finish the patch before alpha3. The RFC an be found here: https://wiki.php.net/rfc/grisu3-strtod - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak references
Hi, On Thu, Jul 14, 2011 at 21:42, Ferenc Kovacs tyr...@gmail.com wrote: To spare the 5.4 features vote thread from the off-topic discussion, we can continue here. Hannes Landeholm brought this idea up, see http://news.php.net/php.internals/53956 and http://news.php.net/php.internals/53959 I would suggest that Hannes create an rfc, and add some examples and introduce the weak references in general and how this can be useful, what problems do they solve (it was discussed in the bugreport, but it wasn't clear as far as I can tell from the comments). if I understand this right, Hannes proposed adding a new Spl class(interface?), which can store and retrive a collection of variables without incrementing the refcounts, so they can be freed if they aren't used other than in this collection. Hannes please correct me if I'm wrong somewhere. Some draft here: https://wiki.php.net/rfc/weakreferences With a patch implementing some magic for a POC here http://patches.colder.ch/php-src/weakref-trunk.patch?markup. It still requires some work though. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
Hi! On 6/29/11 6:31 AM, Mike Willbanks wrote: There's a RFC covering this. There's a patch also. https://wiki.php.net/rfc/splclassloader This one seems to have fallen through the cracks? Well, nobody proposed it in time (especially not the RFC author :) * The other implementation I could see is to modify spl_autoload to be able to pass it a parameter for the auto loading type - right now it will attempt to autoload everything lowercase (been brought up a few times). I think the class looks better. I think RFC needs to be expanded with description of what the class actually does and how, and then if there are no objections I think we could take it into 5.4.0, since the implementation already exists. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak references
Hi, Ferenc: Good idea to move the discussion to a separate thread. Etienne: Awesome. I wish I had time to write the patch myself. I could probably put some hours into adding more details to the RFC though. The only problem as I see it by making it a weak reference class instead of a weak reference collection is that you would end up with a bunch of unnecessary indexes in the array that points to invalid references. The simplest solution to this problem if you still want to implement it as you have begun to is to allow catching the cleanup event in a callback so you can manually unset the index. Should I add these concerns to the RFC? Thanks a bunch, Hannes
Re: [PHP-DEV] deprecating ext/mysql
Hola friends, Nice feedback so far, and the PHP documentation will begin implementing the ideas presented here, and focus on mysqli but also recommend pdo_mysql. Therefore, the ext/mysql documentation will be improved to strongly recommend the preferred alternatives that have existed since PHP 5.0.0. We'll work on the finer details but it feels like procedural mysqli is a better fit to live alongside the ext/mysql examples, although we don't want to confuse people. Maybe geeks here have ideas regarding this, but a clear useful clutter-free solution will be worked out, which may include adjusting the CSS and involve creative linking. I'll add an example or three soonish. However, there has been some confusion within the PHP community, so to help ease these concerns: - This proposal only deals with documentation/education... so it can be described as an official 'soft deprecation' (no errors or code changes) - When (if?) this extension emits errors, or is removed, is not part of this proposal - There is a 100% chance that additional tasks and ideas will be discussed in the future, which might include: - A conversion tool/guide - A wrapper - A PECL extension - Talking to distros/hosters and apps like wordpress - ... - php.net understands that ext/mysql is popular, and we're handling this with extra care and heck, parts of *.php.net is powered by ext/mysql - Seriously, no need to panic We'll document the reasons why the other MySQL extensions are preferred, but if people want to use the old ext/mysql API with PHP 9.0.0 (just an example) then I'm guessing an old geek out there will make that possible. We, however, will do our best to convince users to move towards the preferred and supported methods, and hopefully write better code along the way because honestly, that's the ultimate goal here. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
