Re: [PHP-DEV] Remove sqlite2 from trunk
2010/6/15 Ilia Alshanetsky : > There is way too much code that uses ext/mysql and ext/mysql does not depend > on a legacy library, I don't think we can remove it. As far as mssql, it is > the one way to talk to Microsoft SQL from *nix systems, until there are good > alternatives for a direct interface, I don't think we should remove it. FreeTDS have an odbc wrapper, which means that it will work with ext/odbc and pdo_odbc aswell, the migration is rather simple here and i think it will be beneficial for both us and the users. As for mysql, I know libmysql is maintained, which is fine and all, but I think its time to deprecate it and consider removing it in favour of mysqli which we have been trying to promote. Like johannes said, a wrapper could be written in either native php, or in C level and im willing to help out with that, if thats the way we need to do it. Tutorials and articles that builds on mysql is unfortunate when we want to prommote mysqli, but if we want to change it, i think now is better than never, because people will continue to write articles about it if its still exists within the main distro. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
On Tue, Jun 15, 2010 at 9:26 PM, Ryan Panning wrote: > Ferenc Kovacs wrote: > >> I don't see any mentions about non windows enviroment. >> >> Tyrael >> >> > I thought the ODBTP one was for Unix too. Not sure on other OS's though. > Nor other details, we use MySQL instead, just noticed this documentation. > > > http://docs.moodle.org/en/Installing_MSSQL_for_PHP#Using_ODBTP_on_Unix_or_Windows > http://odbtp.sourceforge.net/ > Sorry, missed that. Tyrael
Re: [PHP-DEV] Remove sqlite2 from trunk
Ferenc Kovacs wrote: I don't see any mentions about non windows enviroment. Tyrael I thought the ODBTP one was for Unix too. Not sure on other OS's though. Nor other details, we use MySQL instead, just noticed this documentation. http://docs.moodle.org/en/Installing_MSSQL_for_PHP#Using_ODBTP_on_Unix_or_Windows http://odbtp.sourceforge.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
On Tue, Jun 15, 2010 at 9:00 PM, Ryan Panning wrote: > Ilia Alshanetsky wrote: > >> There is way too much code that uses ext/mysql and ext/mysql does not >> depend >> on a legacy library, I don't think we can remove it. As far as mssql, it >> is >> the one way to talk to Microsoft SQL from *nix systems, until there are >> good >> alternatives for a direct interface, I don't think we should remove it. >> > > Just FYI. > > I just setup a PHP application for work that mentions the limitations of > the mssql ext. They provided a couple alternatives that they work with. Just > wanted to point out that there are alternatives. > > http://docs.moodle.org/en/Installing_MSSQL_for_PHP > > I don't see any mentions about non windows enviroment. Tyrael
Re: [PHP-DEV] Remove sqlite2 from trunk
Ilia Alshanetsky wrote: There is way too much code that uses ext/mysql and ext/mysql does not depend on a legacy library, I don't think we can remove it. As far as mssql, it is the one way to talk to Microsoft SQL from *nix systems, until there are good alternatives for a direct interface, I don't think we should remove it. Just FYI. I just setup a PHP application for work that mentions the limitations of the mssql ext. They provided a couple alternatives that they work with. Just wanted to point out that there are alternatives. http://docs.moodle.org/en/Installing_MSSQL_for_PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
hi Ilia, On Tue, Jun 15, 2010 at 1:41 PM, Ilia Alshanetsky wrote: > After speaking to a few developers in DPC, I think it makes sense for us to > drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3 > extensions. The sqlite2 library is no longer maintainer and the migration > path from version 2 to 3 is very simple. Unless there any objections, I'd > like to make this happen in the next week or two. No objection here. However I would like to have the set of basic methods (not version specific, exec, open, etc.) to remain the same across versions so the migration could be as simple as using the new name of the sqlite class. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
There is way too much code that uses ext/mysql and ext/mysql does not depend on a legacy library, I don't think we can remove it. As far as mssql, it is the one way to talk to Microsoft SQL from *nix systems, until there are good alternatives for a direct interface, I don't think we should remove it. On Tue, Jun 15, 2010 at 11:45 AM, Kalle Sommer Nielsen wrote: > 2010/6/15 Patrick ALLAERT : > > What about doing the same with MySQL extensions ? > > I have the feeling that there is a benefit at removing ext/mysql with > > the same arguments as for sqlite 2. > > +1 for removing ext/mysql and ext/sqlite. While we are at it, then I > think we should strongly consider removing the ext/mssql extension as > well, its not maintained, there is countless bugs, and its officially > not supported on Windows since 5.3, but it can however still be built > and used if you do it manually. > > > > -- > regards, > > Kalle Sommer Nielsen > ka...@php.net >
Re: [PHP-DEV] Remove sqlite2 from trunk
On Tue, 2010-06-15 at 16:56 +0200, Patrick ALLAERT wrote: > What about doing the same with MySQL extensions ? > > Currently there is 3 main ways to access a MySQL server: > ext/mysql > ext/mysqli > PDO_MYSQL > > Additionally, mysqlnd has to be considered as a possible library for > each of them. > > I have the feeling that there is a benefit at removing ext/mysql with > the same arguments as for sqlite 2. There are a few differences: - The base library SQLite (2) depends on isn't maintained anymore. For mysql these are libmysql and mysqlnd. Both are maintained. - Most applications, tutorials, ... use the mysql_ functions. I would really like to get rid of the old mysql (less code -> less maintenance) extension but assume it will cause lots of pain. I was once thinking about a PHP implementation of a compatibility wrapper based on mysqli. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
On Tue, 2010-06-15 at 07:41 -0400, Ilia Alshanetsky wrote: > After speaking to a few developers in DPC, I think it makes sense for us to > drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3 > extensions. The sqlite2 library is no longer maintainer and the migration > path from version 2 to 3 is very simple. Unless there any objections, I'd > like to make this happen in the next week or two. +1 Anybody objects for adding E_DEPRECATED to sqlite_open() in 5.3? johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
2010/6/15 Elizabeth M Smith : > I'd have to disagree with this for one reason - it currently is the ONLY way > to speak to Sql Server on non-windows machines. Until there is an > alternative it probably needs to stay... So only freetds works when you want to talk to mssql on non-windows? Not even ODBC? There still is pdo_mssql/pdo_dblib -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
On 6/15/2010 11:45 AM, Kalle Sommer Nielsen wrote: 2010/6/15 Patrick ALLAERT: What about doing the same with MySQL extensions ? I have the feeling that there is a benefit at removing ext/mysql with the same arguments as for sqlite 2. +1 for removing ext/mysql and ext/sqlite. While we are at it, then I think we should strongly consider removing the ext/mssql extension as well, its not maintained, there is countless bugs, and its officially not supported on Windows since 5.3, but it can however still be built and used if you do it manually. I'd have to disagree with this for one reason - it currently is the ONLY way to speak to Sql Server on non-windows machines. Until there is an alternative it probably needs to stay... Thanks, Elizabeth Smith -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
2010/6/15 Patrick ALLAERT : > What about doing the same with MySQL extensions ? > I have the feeling that there is a benefit at removing ext/mysql with > the same arguments as for sqlite 2. +1 for removing ext/mysql and ext/sqlite. While we are at it, then I think we should strongly consider removing the ext/mssql extension as well, its not maintained, there is countless bugs, and its officially not supported on Windows since 5.3, but it can however still be built and used if you do it manually. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
What about doing the same with MySQL extensions ? Currently there is 3 main ways to access a MySQL server: ext/mysql ext/mysqli PDO_MYSQL Additionally, mysqlnd has to be considered as a possible library for each of them. I have the feeling that there is a benefit at removing ext/mysql with the same arguments as for sqlite 2. Patrick 2010/6/15 Ilia Alshanetsky : > Just to clarify, removal does not mean deletion, it would simply become a > PECL extension people who need it can still use. > > On Tue, Jun 15, 2010 at 9:30 AM, Adam Harvey wrote: > >> On 15 June 2010 19:41, Ilia Alshanetsky wrote: >> > After speaking to a few developers in DPC, I think it makes sense for us >> to >> > drop the Sqlite2 extensions from Trunk as they are superseded by the >> Sqlite3 >> > extensions. The sqlite2 library is no longer maintainer and the migration >> > path from version 2 to 3 is very simple. Unless there any objections, I'd >> > like to make this happen in the next week or two. >> >> Funnily enough, we had a short discussion about this on IRC last week; >> I was meaning to write an RFC before getting swamped at work. My >> feeling (and I'm speaking just for myself here) is that we can't >> really get rid of ext/sqlite in the short to medium term: people have >> gotten too used to having it available and bundled in a default PHP >> installation. Obviously, though, we can't really keep bundling an >> unmaintained library, either, and we should start nudging people >> gently towards sqlite3. >> >> What I'd prefer: >> >> – Deprecate ext/sqlite in trunk, at least by having sqlite_open() >> generate an E_DEPRECATED warning. >> – Unbundle libsqlite2 in the next major version after what's currently >> in trunk and disable the extension by default, but still allow >> compilation against an external libsqlite2 if the user really wants >> to. >> – Move ext/sqlite to PECL at some point thereafter. >> >> PDO would be handled similarly. >> >> If someone has some real world numbers on the use of ext/sqlite, that >> might be handy. From where I sit, though, it does seem to have become >> a bit of a standard, so I'd rather not pull the rug out from under >> people that suddenly — particularly given it's not even deprecated at >> the moment. >> >> Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: ben
On 15/06/10 10:28, Derick Rethans wrote: > I've given you */tests karma, but please send the first few patches past > php.qa before you commit them. Done, and commited. Thanks for sorting this for me! Ben -- http://nocarrier.co.uk twitter: @blongden -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
Just to clarify, removal does not mean deletion, it would simply become a PECL extension people who need it can still use. On Tue, Jun 15, 2010 at 9:30 AM, Adam Harvey wrote: > On 15 June 2010 19:41, Ilia Alshanetsky wrote: > > After speaking to a few developers in DPC, I think it makes sense for us > to > > drop the Sqlite2 extensions from Trunk as they are superseded by the > Sqlite3 > > extensions. The sqlite2 library is no longer maintainer and the migration > > path from version 2 to 3 is very simple. Unless there any objections, I'd > > like to make this happen in the next week or two. > > Funnily enough, we had a short discussion about this on IRC last week; > I was meaning to write an RFC before getting swamped at work. My > feeling (and I'm speaking just for myself here) is that we can't > really get rid of ext/sqlite in the short to medium term: people have > gotten too used to having it available and bundled in a default PHP > installation. Obviously, though, we can't really keep bundling an > unmaintained library, either, and we should start nudging people > gently towards sqlite3. > > What I'd prefer: > > – Deprecate ext/sqlite in trunk, at least by having sqlite_open() > generate an E_DEPRECATED warning. > – Unbundle libsqlite2 in the next major version after what's currently > in trunk and disable the extension by default, but still allow > compilation against an external libsqlite2 if the user really wants > to. > – Move ext/sqlite to PECL at some point thereafter. > > PDO would be handled similarly. > > If someone has some real world numbers on the use of ext/sqlite, that > might be handy. From where I sit, though, it does seem to have become > a bit of a standard, so I'd rather not pull the rug out from under > people that suddenly — particularly given it's not even deprecated at > the moment. > > Adam >
Re: [PHP-DEV] Remove sqlite2 from trunk
On 15 June 2010 19:41, Ilia Alshanetsky wrote: > After speaking to a few developers in DPC, I think it makes sense for us to > drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3 > extensions. The sqlite2 library is no longer maintainer and the migration > path from version 2 to 3 is very simple. Unless there any objections, I'd > like to make this happen in the next week or two. Funnily enough, we had a short discussion about this on IRC last week; I was meaning to write an RFC before getting swamped at work. My feeling (and I'm speaking just for myself here) is that we can't really get rid of ext/sqlite in the short to medium term: people have gotten too used to having it available and bundled in a default PHP installation. Obviously, though, we can't really keep bundling an unmaintained library, either, and we should start nudging people gently towards sqlite3. What I'd prefer: – Deprecate ext/sqlite in trunk, at least by having sqlite_open() generate an E_DEPRECATED warning. – Unbundle libsqlite2 in the next major version after what's currently in trunk and disable the extension by default, but still allow compilation against an external libsqlite2 if the user really wants to. – Move ext/sqlite to PECL at some point thereafter. PDO would be handled similarly. If someone has some real world numbers on the use of ext/sqlite, that might be handy. From where I sit, though, it does seem to have become a bit of a standard, so I'd rather not pull the rug out from under people that suddenly — particularly given it's not even deprecated at the moment. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Remove sqlite2 from trunk
After speaking to a few developers in DPC, I think it makes sense for us to drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3 extensions. The sqlite2 library is no longer maintainer and the migration path from version 2 to 3 is very simple. Unless there any objections, I'd like to make this happen in the next week or two. Ilia
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/ext/pdo/pdo_dbh.c branches/PHP_5_3/ext/pdo/php_pdo_driver.h branches/PHP_5_3/ext/pdo_pgsql/pdo_pgsql.c branches/PHP_
I'll adjust the code to simply use in_txn flag for the moment to avoid the structure change. 2010/6/14 Johannes Schlüter > On Thu, 2010-06-10 at 12:11 +, Ilia Alshanetsky wrote: > > Modified: php/php-src/branches/PHP_5_3/ext/pdo/php_pdo_driver.h > > === > > --- > > php/php-src/branches/PHP_5_3/ext/pdo/php_pdo_driver.h 2010-06-10 > > 11:45:51 UTC (rev 300350) > > +++ > > php/php-src/branches/PHP_5_3/ext/pdo/php_pdo_driver.h 2010-06-10 > > 12:11:19 UTC (rev 300351) > > @@ -310,6 +310,7 @@ > > pdo_dbh_check_liveness_func check_liveness; > > pdo_dbh_get_driver_methods_func get_driver_methods; > > pdo_dbh_request_shutdownpersistent_shutdown; > > + pdo_dbh_txn_funcin_transaction; > > }; > > > > /* }}} */ > > Here you are changing a structure which is allocated and initialized in > a driver and then read from the PDO core. PDO core will therefore read > invalid memory when a driver compiled against 5.3.2 is used in 5.3.3 > while we usually guarantee binary compatibility in bug fix releases. > > This for instance affects distributors or MSFT's sqlsrv driver. > > johannes > > > >
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
Pierre, That is not your decision, since when do you decide what goes into PDO, that's a decision between the extension maintainer and the release master and since you are neither... On Mon, Jun 14, 2010 at 12:06 PM, Pierre Joye wrote: > On Sat, Jun 12, 2010 at 12:24 PM, Pierre Joye > wrote: > > hi Ilia, > > > > So you basically say that the worries and wishes raised here are > > simply irrelevant and at the end of the day you decide what PDO can or > > cannot be? > > > > I'm very disappointed by these two commits. I don't think it is the > > way we should develop PDO and it is clear that I'm not the only one to > > think that. As it is trunk, I won't battle too much to revert it but > > be sure that is not something I will let in for any of the upcoming > > releases as it is clearly bad design. > > I did not see that you even committed that to 5.3. That's definitively a no > go. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >
Re: [PHP-DEV] SVN Account Request: ben
On Tue, 15 Jun 2010, Ben Longden wrote: > I have been writing tests for the spl extension and would like to > submit them. Having asked in php.qa I have been advised to ask for an > svn account. I've given you */tests karma, but please send the first few patches past php.qa before you commit them. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SVN Account Request: ben
I have been writing tests for the spl extension and would like to submit them. Having asked in php.qa I have been advised to ask for an svn account. I already have some tests in svn through the testfest svn repositories however I am no longer able to commit via that particular route. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
