# Remove sqlite2 from trunk - Thread: https://externals.io/message/48785 - Original archive: https://news-web.php.net/php.internals/48785 - Started by Ilia Alshanetsky on 2010-06-15T11:41:15+00:00 - Messages: 32 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/48785.md?page=2 - 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 --- ## #48785 — Ilia Alshanetsky — 2010-06-15T11:41:15+00:00 URL: https://externals.io/message/48785#48785 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 --- ## #48786 — Adam Harvey — 2010-06-15T13:30:57+00:00 URL: https://externals.io/message/48785#48786 · In reply to: #48785 > 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 --- ## #48787 — Ilia Alshanetsky — 2010-06-15T14:01:41+00:00 URL: https://externals.io/message/48785#48787 · In reply to: #48786 Just to clarify, removal does not mean deletion, it would simply become a PECL extension people who need it can still use. > > > […] > to > > […] > Sqlite3 > > […] > > 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 --- ## #48789 — Patrick ALLAERT — 2010-06-15T14:56:29+00:00 URL: https://externals.io/message/48785#48789 · In reply to: #48787 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. > > > > > […] --- ## #48790 — Kalle Sommer Nielsen — 2010-06-15T15:45:48+00:00 URL: https://externals.io/message/48785#48790 · In reply to: #48789 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 kalle@php.net --- ## #48791 — Elizabeth M Smith — 2010-06-15T15:49:43+00:00 URL: https://externals.io/message/48785#48791 · In reply to: #48790 > 2010/6/15 Patrick ALLAERT: > > […] > > +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 --- ## #48792 — Kalle Sommer Nielsen — 2010-06-15T15:58:22+00:00 URL: https://externals.io/message/48785#48792 · In reply to: #48791 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 kalle@php.net --- ## #48793 — johannes@schlueters.de — 2010-06-15T17:02:49+00:00 URL: https://externals.io/message/48785#48793 · In reply to: #48785 > 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 --- ## #48794 — Johannes.Schlueter@Sun.COM — 2010-06-15T17:12:05+00:00 URL: https://externals.io/message/48785#48794 · In reply to: #48789 > 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 --- ## #48795 — Ilia Alshanetsky — 2010-06-15T18:11:47+00:00 URL: https://externals.io/message/48785#48795 · In reply to: #48790 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 : > > […] > > +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 > kalle@php.net --- ## #48796 — Pierre Joye — 2010-06-15T18:18:18+00:00 URL: https://externals.io/message/48785#48796 · In reply to: #48785 hi Ilia, > 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 --- ## #48797 — Ryan Panning — 2010-06-15T19:00:05+00:00 URL: https://externals.io/message/48785#48797 · In reply to: #48795 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 --- ## #48798 — Ferenc Kovacs — 2010-06-15T19:06:41+00:00 URL: https://externals.io/message/48785#48798 · In reply to: #48797 > Ilia Alshanetsky wrote: > > > […] > > 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 --- ## #48799 — Ryan Panning — 2010-06-15T19:26:46+00:00 URL: https://externals.io/message/48785#48799 · In reply to: #48798 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/ --- ## #48800 — Ferenc Kovacs — 2010-06-15T19:49:42+00:00 URL: https://externals.io/message/48785#48800 · In reply to: #48799 > Ferenc Kovacs wrote: > > > […] > 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 --- ## #48801 — Kalle Sommer Nielsen — 2010-06-15T22:49:12+00:00 URL: https://externals.io/message/48785#48801 · In reply to: #48795 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 kalle@php.net --- ## #48802 — Ilia Alshanetsky — 2010-06-16T11:04:09+00:00 URL: https://externals.io/message/48785#48802 · In reply to: #48796 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... > hi Ilia, > > On Tue, Jun 15, 2010 at 1:41 PM, Ilia Alshanetsky > wrote: > > […] > to > > […] > Sqlite3 > > […] > > > 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 --- ## #48804 — Pierre Joye — 2010-06-16T11:17:35+00:00 URL: https://externals.io/message/48785#48804 · In reply to: #48802 > 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 --- ## #48805 — Ilia Alshanetsky — 2010-06-16T12:00:50+00:00 URL: https://externals.io/message/48785#48805 · In reply to: #48804 Why not just have a PHP based wrapper that would extend SQLite3 class as SQLite2 equivalent... > On Wed, Jun 16, 2010 at 1:04 PM, Ilia Alshanetsky > wrote: > > […] > extension > > […] > be > > […] > > 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 --- ## #48806 — Will Bond — 2010-06-16T13:14:31+00:00 URL: https://externals.io/message/48785#48806 · In reply to: #48801 > 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. --- ## #48808 — Andrey Hristov — 2010-06-16T17:43:52+00:00 URL: https://externals.io/message/48785#48808 · In reply to: #48801 Kalle, Kalle Sommer Nielsen wrote: > 2010/6/15 Ilia Alshanetsky : > > […] > > 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 --- ## #48816 — Derick Rethans — 2010-06-17T09:23:17+00:00 URL: https://externals.io/message/48785#48816 · In reply to: #48789 > 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 --- ## #48818 — Mike Robinson — 2010-06-17T15:12:17+00:00 URL: https://externals.io/message/48785#48818 · In reply to: #48816 On June-17-10 5:23 AM Derick Rethans wrote: > > > > > […] > > I would be against that. > > Derick = sigh of relief = The voice of reason. Best Regards, Mike Robinson --- ## #48819 — Pierre Joye — 2010-06-17T16:44:12+00:00 URL: https://externals.io/message/48785#48819 · In reply to: #48818 > On June-17-10 5:23 AM Derick Rethans wrote: > > > […] > > = 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 --- ## #48823 — Mike Robinson — 2010-06-17T22:43:31+00:00 URL: https://externals.io/message/48785#48823 · In reply to: #48819 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 > > > > […] > for > > […] > with > > […] > > 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 --- Next page: https://externals.io/message/48785.md?page=2