[development] SQLite and Drupal 7 -- third coming

[Victor Kane]

Drupal Lite!

On Wed, Feb 4, 2009 at 9:16 PM, Jamie Holly <hovercrafter at earthlink.net>wrote:

> 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
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20090204/0943e54d/attachment.htm