Re: [PHP-DEV] Remove sqlite2 from trunk
2010/8/11 Johannes Schlüter : > Hi, > > trying to get back to productive issues: > > 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. > > I think the consensus here is to drop the extension and the pdo_sqlite2 > driver. Should we add deprecation notices to sqlite_open() and the PDO > driver ctor? > > Any other comments (CC'ing the webmaster list as the PHP Web site > depends heavily on SQLite2) Most of our mirrors have other sqlite extensions available, so its just up to us to generate the sqlite3 databse. I find this sqlite situation very annoying, but I do agree with killing the no-longer-supported variations :) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
Hi, trying to get back to productive issues: 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. I think the consensus here is to drop the extension and the pdo_sqlite2 driver. Should we add deprecation notices to sqlite_open() and the PDO driver ctor? Any other comments (CC'ing the webmaster list as the PHP Web site depends heavily on SQLite2) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
On Fri, Jun 18, 2010 at 7:50 PM, Jonathan Bond-Caron wrote: > SQLITE_API int sqlite3_busy_timeout(sqlite3*, int ms); > > b) No persistent connections > > Any reason why it wasn't migrated from sqlite.c? It is now in trunk. 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
On 20.06.2010, at 12:01, Ulf Wendel wrote: > Johannes Schlüter schrieb: >> On Sat, 2010-06-19 at 12:45 +0200, Sebastian Bergmann wrote: >>> 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 m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
Johannes Schlüter schrieb: On Sat, 2010-06-19 at 12:45 +0200, Sebastian Bergmann wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove ext/mysql from trunk? (was: Re: [PHP-DEV] Remove sqlite2 from trunk)
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 BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove ext/mysql from trunk? (was: Re: [PHP-DEV] Remove sqlite2 from trunk)
On Sat, 2010-06-19 at 12:45 +0200, Sebastian Bergmann wrote: > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove ext/mysql from trunk? (was: Re: [PHP-DEV] Remove sqlite2 from trunk)
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 BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Remove ext/mysql from trunk? (was: Re: [PHP-DEV] Remove sqlite2 from trunk)
2010/6/19 Ulf Wendel : > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
On Jun 18, 2010, at 10:50 AM, Jonathan Bond-Caron wrote: > On Wed Jun 16 07:04 AM, Ilia Alshanetsky wrote: 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. >>> > > I'm all for starting to use sqlite3 but I found two issues with the > migration to the new api: > > a) sqlite_busy_timeout is not available in sqlite3.c > > This is important for an application to return a failure right away instead > of wait for locks to be release. > The patch looks simple since it's a wrapper for There is a patch going around, someone should commit it or I will. > > SQLITE_API int sqlite3_busy_timeout(sqlite3*, int ms); > > b) No persistent connections > > Any reason why it wasn't migrated from sqlite.c? > Persistent connections make sense if there is an actual overhead in creating a socket etc, it doesn't really apply and is actually more dangerous if something is left unfinished and locks the DB. - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Remove sqlite2 from trunk
On Wed Jun 16 07:04 AM, Ilia Alshanetsky wrote: > > > 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. > > I'm all for starting to use sqlite3 but I found two issues with the migration to the new api: a) sqlite_busy_timeout is not available in sqlite3.c This is important for an application to return a failure right away instead of wait for locks to be release. The patch looks simple since it's a wrapper for SQLITE_API int sqlite3_busy_timeout(sqlite3*, int ms); b) No persistent connections Any reason why it wasn't migrated from sqlite.c? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Remove sqlite2 from trunk
On Thu, 2010-06-17 at 18:43 -0400, Mike Robinson wrote: > On June-17-10 12:44 PM Pierre Joye wrote: > > The only voice that matters here is the voice of the mysql team, they > > know if it is still widely used or not, and how :) The voice that matters is internals at large. > Really? Seriously, how could they reliably know that? :) > > I still like the "I would be against that", notwithstanding. 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... 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 June-17-10 12:44 PM Pierre Joye wrote: > Sent: June-17-10 12:44 PM > To: Mike Robinson > Cc: Derick Rethans; Patrick ALLAERT; Ilia Alshanetsky; Adam Harvey; > internals@lists.php.net > Subject: Re: [PHP-DEV] Remove sqlite2 from trunk > > On Thu, Jun 17, 2010 at 5:12 PM, Mike Robinson wrote: > > On June-17-10 5:23 AM Derick Rethans wrote: > > > >> > >> On Tue, 15 Jun 2010, 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. > >> > >> I would be against that. > >> > >> Derick > > > > = sigh of relief = > > > > The voice of reason. > > The only voice that matters here is the voice of the mysql team, they > know if it is still widely used or not, and how :) Really? Seriously, how could they reliably know that? :) I still like the "I would be against that", notwithstanding. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
On Thu, Jun 17, 2010 at 5:12 PM, Mike Robinson wrote: > On June-17-10 5:23 AM Derick Rethans wrote: > >> >> On Tue, 15 Jun 2010, 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. >> >> I would be against that. >> >> Derick > > = sigh of relief = > > The voice of reason. The only voice that matters here is the voice of the mysql team, they know if it is still widely used or not, and how :) -- 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
On June-17-10 5:23 AM Derick Rethans wrote: > > On Tue, 15 Jun 2010, 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. > > I would be against that. > > Derick = sigh of relief = The voice of reason. Best Regards, Mike Robinson -- 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, 15 Jun 2010, 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. I would be against that. 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
Re: [PHP-DEV] Remove sqlite2 from trunk
Kalle, Kalle Sommer Nielsen wrote: 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. since ages a tool exists : http://forge.mysql.com/wiki/Converting_to_MySQLi which converts calls to mysql in calls to mysqli. The result might not be pretty but works. As far as I recall it was tested with phpMyAdmin and worked. 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. Andrey -- 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 6:49 PM, Kalle Sommer Nielsen wrote: > 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. I've used the mssql extension quite a bit where I work to connect to SQL Server boxes and I also maintain a cross-extension database library that works with mssql, odbc, pdo_odbc and many more. From my experience, mssql is the only way to connect to a SQL Server database from a non-windows platform – obdc and pdo_odbc had enough unresolvable issues that I disabled the unit tests on every OS except for Windows. If you are interested I can run the SQL Server tests for odbc and pdo_odbc on various platforms and give you some examples of how they fail. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
Why not just have a PHP based wrapper that would extend SQLite3 class as SQLite2 equivalent... On Wed, Jun 16, 2010 at 7:17 AM, Pierre Joye wrote: > On Wed, Jun 16, 2010 at 1:04 PM, Ilia Alshanetsky > wrote: > > Pierre, > > If they are using PDO there are no issue, but when it comes to the > extension > > the Sqlite3 interface is more similar to PDO in naming conventions and > > offers only OO interface. The SQLite2 offers both OO and procedural > > interface and follows its own naming convention. I don't think we should > be > > added boat-load of wrappers for SQLite3 extension... > > That's why I explicitly mentioned 'basic' methods (exec, query and > similar), the python bindings do it for example. It makes obviously no > sense to do it for many advanced features. SQlite3 APIs allow that > easily (cleaner naming). > > 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
On Wed, Jun 16, 2010 at 1:04 PM, Ilia Alshanetsky wrote: > Pierre, > If they are using PDO there are no issue, but when it comes to the extension > the Sqlite3 interface is more similar to PDO in naming conventions and > offers only OO interface. The SQLite2 offers both OO and procedural > interface and follows its own naming convention. I don't think we should be > added boat-load of wrappers for SQLite3 extension... That's why I explicitly mentioned 'basic' methods (exec, query and similar), the python bindings do it for example. It makes obviously no sense to do it for many advanced features. SQlite3 APIs allow that easily (cleaner naming). 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
Pierre, If they are using PDO there are no issue, but when it comes to the extension the Sqlite3 interface is more similar to PDO in naming conventions and offers only OO interface. The SQLite2 offers both OO and procedural interface and follows its own naming convention. I don't think we should be added boat-load of wrappers for SQLite3 extension... On Tue, Jun 15, 2010 at 2:18 PM, Pierre Joye wrote: > 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 >
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] 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
