Hello Wez, Wednesday, October 20, 2004, 2:29:52 PM, you wrote:
> Quoting hell, but please bear with it.... >> [EMAIL PROTECTED] writes: >> > "julien" <[EMAIL PROTECTED]> writes: >> >> does anyone know if PHP will integrate SQLite3 per default in version 5.1 ? >> >> Actually PHP 5.0.2 include only SQLite2. >> > >> > The plan _is_ to integrate SQLite3. There are two of us who may integrate >> > it, depending on availability and need. There's no schedule for when it >> > will be completed, but it is reasonably high on some of our priority lists. > We have an SQLite 3 driver for PDO in CVS. It makes use of bound > parameters etc. and is feature complete, except for UDF support (that > will be completed "soon"). > PDO is something that quite a few of us want to see as the recommended > database API for PHP 5.1. We haven't laid any definite plans for the > 5.1 feature list yet (it's probably a good time for us to start > thinking about that here on internals@) so there is not yet an > official line on PDO or SQLite 3. > With the improved concurrency, presence of real binary support > (without encoding hacks), bound parameters and total unicode support > in SQLite3, and given that we already have sqlite 2 bundled, I think > there is a strong case for having it present in the default > distribution. >> "julien" <[EMAIL PROTECTED]> writes: >> > thank you for your answer. I put this question because compatibility between >> > ant will choose sqlite in the futur and migrate this application). Moreover >> > recompile PHP5.0.2 with SQLite3 (under windows platform ...) is too >> > difficult and is impossible on my production web server. So i'm very >> > impatient :)) > It is impossible in any case because the API's, although similar, are > not compatible. >> "D. Richard Hipp" <[EMAIL PROTECTED]> writes: >> > SQLite3 is designed so that it can be statically linked into the same >> > executable as SQLite2. One plan for PHP might be to link in both libraries. >> > When opening an existing database, check the header and use either the >> > SQLite2 or the SQLite3 library depending on what kind of database it is. >> > Create new databases as SQLite3. The scripting interface would be the >> > same and the user would never know the difference. In this way, you >> > preserve backwards compatibility with existing SQLite2 database files >> > while at the same time taking advantage of new SQLite3 features. > While this is a nice idea, I can't see it working in the context of > the existing PHP sqlite extension. The biggest killer is binary > support; PHP automatically encodes binary strings, and this will break > in sqlite 3. The next biggest killer is that PHP builds sqlite 2 in > latin1 mode by default (utf-8 implementation in sqlite 2 at that time > was not suitable for use in a web server context), and sqlite 3 is > utf-8/unicode only. That would require charset encoding to be handled > automagically. > Adding a lot of code to PHP to handle the differences is going to be > awful, to say the least; it's quite a high maintenance burden to take > on, particularly when we are beginning to shift focus to PDO. > IMO, it is better to keep sqlite 2 and sqlite 3 separate; there is > less chance for things to break that way. Same thoughts from here. Since i assume Ilia will agree too that's already a decision. > Can we expect sqlite 4 to evolve in a similar way? i hope not...and if we will simply provide a sqlite v4 pdo driver > --Wez (@php.net) -- Best regards, Marcus mailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
