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. Can we expect sqlite 4 to evolve in a similar way? --Wez (@php.net) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
