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
2010/8/11 Johannes Schlüter johan...@schlueters.de:
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
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
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
On Fri, Jun 18, 2010 at 7:50 PM, Jonathan Bond-Caron jbo...@openmv.com 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
2010/6/19 Ulf Wendel ulf.wen...@phpdoc.de:
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
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
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
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.
--
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
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
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
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
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
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
On Thu, Jun 17, 2010 at 5:12 PM, Mike Robinson m...@rile.ca 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
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 m...@rile.ca
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
On Wed, Jun 16, 2010 at 1:04 PM, Ilia Alshanetsky i...@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
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 pierre@gmail.com wrote:
On Wed, Jun 16, 2010 at 1:04 PM, Ilia Alshanetsky i...@prohost.org
wrote:
Pierre,
If they are using PDO there are no
On Tue, Jun 15, 2010 at 6:49 PM, Kalle Sommer Nielsen ka...@php.net 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
Kalle,
Kalle Sommer Nielsen wrote:
2010/6/15 Ilia Alshanetsky i...@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
On 15 June 2010 19:41, Ilia Alshanetsky i...@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
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 ahar...@php.net wrote:
On 15 June 2010 19:41, Ilia Alshanetsky i...@prohost.org wrote:
After speaking to a few developers in
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
2010/6/15 Patrick ALLAERT patrick.alla...@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
On 6/15/2010 11:45 AM, Kalle Sommer Nielsen wrote:
2010/6/15 Patrick ALLAERTpatrick.alla...@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
2010/6/15 Elizabeth M Smith auroraeosr...@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
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
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
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
hi Ilia,
On Tue, Jun 15, 2010 at 1:41 PM, Ilia Alshanetsky i...@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
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
On Tue, Jun 15, 2010 at 9:00 PM, Ryan Panning rpann...@gmail.com 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
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.
On Tue, Jun 15, 2010 at 9:26 PM, Ryan Panning rpann...@gmail.com 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
2010/6/15 Ilia Alshanetsky i...@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
37 matches
Mail list logo
