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
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
Just to clarify, removal does not mean deletion, it would simply become a
PECL extension people who need it can still use.
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 anE_DEPRECATEDwarning.
– 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
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 ilia@prohost.org:
Just to clarify, removal does not mean deletion, it would simply become a
PECL extension people who need it can still use.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 anE_DEPRECATEDwarning.
– 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
2010/6/15 Patrick ALLAERT patrick.allaert@gmail.com:
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
2010/6/15 Patrick ALLAERTpatrick.allaert@gmail.com:
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
2010/6/15 Elizabeth M Smith auroraeosrose@gmail.com:
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
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 kalle@php.netwrote:
2010/6/15 Patrick ALLAERT patrick.allaert@gmail.com:
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
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.
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.
I don't see any mentions about non windows enviroment.
Tyrael
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
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
2010/6/15 Ilia Alshanetsky ilia@prohost.org:
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
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.
Kalle,
Kalle Sommer Nielsen wrote:
2010/6/15 Ilia Alshanetsky ilia@prohost.org:
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
What about doing the same with MySQL extensions ?
Currently there is 3 main ways to access a MySQL server:
ext/mysql
ext/mysqli
PDO_MYSQLAdditionally, 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
What about doing the same with MySQL extensions ?
Currently there is 3 main ways to access a MySQL server:
ext/mysql
ext/mysqli
PDO_MYSQLAdditionally, 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
On June-17-10 5:23 AM Derick Rethans 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_MYSQLAdditionally, 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
On June-17-10 5:23 AM Derick Rethans 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_MYSQLAdditionally, 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
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 trunkOn June-17-10 5:23 AM Derick Rethans 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_MYSQLAdditionally, 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
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
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
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
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
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 ilia@prohost.org
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
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
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 ilia@prohost.org
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
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?
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
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
Hi,
trying to get back to productive issues:
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
2010/8/11 Johannes Schlüter johannes@schlueters.de:
Hi,
trying to get back to productive issues:
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