Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23053
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <0c4501c66c5d$7fe6fa80$6602a8c0@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: "Wez Furlong" <kingwez@gmail.com>
Cc: "internals" <internals@lists.php.net>
References: <0ba601c66c4e$1f1b4e90$6602a8c0@foxbox> <4e89b4260604300623mded05a3of1b2a867205424c2@mail.gmail.com> <0c3c01c66c5a$36350a60$6602a8c0@foxbox>
Date: Sun, 30 Apr 2006 15:53:44 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="Windows-1252";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH] win32, PDO and the SQLite build
From: steph@zend.com ("Steph Fox")

> On 4/30/06, Steph Fox <steph@zend.com> wrote:
>> The attached patch makes it possible to build either php_sqlite.dll 
>> without
>> the PDO dependency, or php_pdo_sqlite2.dll with the PDO dependency.
>
> That means that you end up with php_pdo_sqlite2.dll only in the
> official snapshot builds.

Yes - because it has PDO support. That's exactly the same situation we 
already have in win32 snaps, except that it doesn't declare itself. This way 
it _does_ declare itself, removing a tiny bit of WTF-ness from the lives of 
win32/PHP users everywhere :)

>> I'm hoping it'll mean you can consider enabling built-in sqlite by 
>> default
>> again, even if PDO isn't quite ready for that yet?
>
> It's got nothing to do with PDO "being ready".  The only reason that
> the sqlite2 driver is part of the sqlite2 extension is because we
> include a bundled sqlite2 library.

I've asked several times why PDO isn't enabled by default. Having had no 
answer, I assumed it was because it's still marked EXPERIMENTAL - and in 
fact that's the only answer anyone else could come up with too.

> I still don't see why you think that you need everything to be
> compiled into PHP statically on windows--we ship *all* the binaries
> that you might need, and everybody knows how to edit php.ini to turn
> on the bits they are missing.

Everybody knows you HAVE to enable PDO in order to run SQLite 2 in PHP 5.1, 
despite the fact that SQLite 2 was statically built-in throughout the 5.0 
series and despite the fact that there's nothing in the sqlite library name 
to make that relationship obvious?  Are you sure?

I don't want *everything* to be statically built in. I think having no 
built-in database support in PHP is basically wrong because it's not what 
users are used to; I think SQLite, having been there before, should never 
have been removed in the way it was in the first place; and I think PDO 
should be statically built-in by default because it's one less thing for 
people to remember when they're enabling their chosen PDO drivers. 
PDO_SQLite should also be in there because people should be moving to it, 
but SQLite 2 - being used in PHP 4 code as well as PHP 5 code - should be 
supported, and this seems the best way of ensuring that it always is.

The part I really don't understand is why you don't see there's a problem 
with the status quo. What arguments are there against built-in database 
support, other than 'we ship all the binaries anyway'?

- Steph