[development] SQLite and Drupal 7 -- let's try this again

[Karoly Negyesi]

> So, what you're roughly saying is:
> 
>   * the speed of a file read/parse of a SQLite table
>     is always going to be faster than a MySQL/etc. read?

That's likely but that's not the big win here. Read on.

>   * Aesthetically, I like being able to see what's in a database. I don't
>     personally know how to access a SQLite database, nor do I want to.

Well, there is a command line utility but sure.

>   * When I'm debugging, it tends to be useful to quickly modify up/down
>     the weight of a module stored in, yep, the system table. Would I
>     still be able to do that here, from a MySQL prompt? 

>From a sqlite prompt. Not a big difference IMO. The changes from SQLite will not, however, automatically sync back to MySQL so I admit this is not ideal. 

It seems I need to make sure that Drupal can pull together itself enough to rebuild the missing SQLite database by copying the tables from MySQL. And then reload itself in a useable state. This means that actually deploy is a lot lot easier than I originally thought. (See this is why I am not too fond of emails, I like the issue queue a lot better)
 
>   * Are the gains *really* so incredibly huge that SQLite is the only
>     solution, as opposed to "just" throwing the same ol' chainsaws at
>     the problem: memcached, opcode cache, etc.? If this is so great
>     for high-profile sites, they've probably already got their own
>     specific set of tweaks for improving things, no? (I know I do.)

Here we go. The big win is NOT performance. The big win is nice code. I forgot to mention this, silly me. So the problem is that currently we have a fairly ugly way to allow pluggable subsystems and they are not really flexible. You can pick one cache subsystem, that's it. We are planning something called handlers which will let you pick cache subsystems by the table for example. For this, we will change the cache implementations to become a class. However, if we want -- and yes, we want -- to serve cached pages without touching MySQL then we need to somehow specify the pathes to the cache and session implementation. If we have the registry available immediately then autoload just works. 
 
>   * "Therefore, when people with high performance sites deploy their
>     new code, they can deploy the new database." Where is this new SQLite
>     file being created?

In your files directory because it needs to be Apache writeable but it's kinda irrevelant here.