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 Sqli
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
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.
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/
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 mysq
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.
--
Seb
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
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 re
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 be
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 art
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 versio
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
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,
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,
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
>> > e
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
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 t
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
a
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
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
> ex
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
> interfa
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 b
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 interf
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 docume
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_ODB
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 s
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'
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 migratio
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 i
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.
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
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
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
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 remov
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 s
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 f
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 versio
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'
38 matches
Mail list logo
