[development] SQLite and Drupal 7 -- third coming

[Jamie Holly]

What impact would this have on sites utilizing multiple Apache/PHP 
servers? I'm not that up on SQLite, but I was always under the 
impression it was more or less designed for a single server scenario 
(though I guess you could put the file on a shared file system, which of 
course opens up a whole new can of worms).

Jamie Holly




Larry Garfield wrote:
> So I am still -1 on requiring SQLite in order for Drupal to function.  However, I am leaning more and more toward automatically using it if available.
>
> I am still not convinced that we can always assume PHP 5.2 => SQLite with no further effort.  Some distros do weird things (eg, Debian as someone mentioned already).  I also think the ability to do a complete migration or backup just using the primary DB is a critically important feature for maintainability, and having to migrate a magical file on disk as well is a major WTF for users used to WordPress.  (And let's face it, that's a major market we need to be able to hit.)
>
> However, the idea of treating it as a cache-like system has a lot of merit, especially as it is possible to then run without it.  It's possible (although not recommended) to run without the CSS compressor, clean URLs, etc.  A "system cache SQLite database" could be treated in the same way.
>
> That is, the logic in bootstrap would be something like:
>
> if (we can open the magic DB) {
>   Open it and assign it to connection key default, target "system".
> }
> elseif (it doesn't exist) {
>   Try to create it.
>   Populate it off of the main DB.
>   Open it and assign it to connection key default, target "system".
> }
> elseif (we can't create the DB) {
>   Do nothing.  Queries run against the "system" target will just run against the main DB on their own.
> }
>
> OK, we'll probably want to speed optimize that somewhat since it's on the critical path, but you get the idea.  Then a drupal_flush_caches() would simply delete that DB.
>
> On the installer front, what if installers do not REQUIRE an SQLite to work, but require them for certain features?  So "advanced" install profiles can require SQLite, but the basic ones don't.
>
> --Larry Garfield
>
> On Wed, 4 Feb 2009 07:12:46 -0800, Karoly Negyesi <karoly at negyesi.net> wrote:
> > Hi,
> > 
> > Every morning, I am distilling the discussion.
> > 
> > *) SQLite is not supported. If you have Drupal 5.2 and PDO which are
> > already requirements then you have SQLite unless it's explicitly
> > disabled and so far noone was able to answer the challenge at
> > http://drupal4hu.com/node/177 . It's embedded into PHP so "supporting"
> > it is like supporting the SimpleXML extension. Unlike MySQL where you
> > need to run a separate server, here we have an embedded SQL engine
> > right inside PDO. Also note that if we want (and I think we want)
> > easier and more powerful install profiles then we will require SQLite
> > for the install anyways.
> > 
> > *) Deployment and rebuild. As it stands, now I believe that Drupal
> > should be able to boot up enough to be able to copy the tables from
> > MySQL to SQLite. I am not saying I am expecting it to be functional.
> > After the tables are copied back into SQLite, it should either restart
> > the bootstrap process or reload at the same URL. This solves
> > deployment.
> > 
> > *) Why do I want this? Once again, nicer code, especially for caching.
> > Various pluggable subsystems (cache, session and path being the
> > biggest wins here)  will just work instead of ugly hacking. But in
> > general, instead of trying to figure out during bootstrap coding "do
> > we have a DB connection yet" the answer is always yes.
> > 
> > Kind regards
> > 
> > NK
>
>
>