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

[Morbus Iff]

> Drupal 7 has a very interesting new feature which we call the
> registry. The registry holds information about which function, class
> and interface lives in which file. This information never changes if
> you do not change your modules and themes.
> 
> Drupal always had a system table which holds information on available
> themes and modules. This information never changes if you do not add
> new modules nor new themes.
> 
> If we put these tables in an SQLite table then the only time this file
> changes is when your code changes. Therefore, when people with high
> performance sites deploy their new code, they can deploy the new
> database. There is no new procedure to be created, just one more file

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?

Even if the above is true, I'm not a huge, huge fan of it myself. Is 
there an automatic backup in place - something that, if SQLite is 
enabled, but the SQLite database isn't there (or can't be created), we'd 
fall back to the MySQL version?

Random comments and reasons for disliking it:

  * Not immediately easy to explain. What's this file doing here? Why
    is Drupal the only application I know that requires both SQLite
    and a MySQL store? Why isn't everything in MySQL? Why aren't more
    things in SQLite?

  * Generally speaking, "backup your databases" and "backup your site"
    happen in two separate mental processes (and usually technical
    processes too). Unless the feature handles a failsafe when the SQLite
    database goes missing, I'm not too happy with the idea of "ok, to
    backup the 'database' now requires a mysqldump AND a copy of this
    SQLite database."

  * 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.

  * Similarly, in Drupal 6 (I dunno about Drupal 7), the system table
    is also NOT UPDATED when I *remove* modules or themes. I regularly
    am pruning it manually, because it bugs me. I'm obsessive about
    cleanliness and organization. Unless I move the DELETE FROM {system}
    code to a module, you're implying I can't do that anymore?

  * 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? Or would I have
    to devolve into learning SQLite again, when I've never ever had to
    use SQLite ever?

  * 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.)

  * "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? This particular comment, I dunno, feels ooky to
    me. When I deploy code, I want to, you know, deploy *code*, not a
    set of caches (for the same reason that I don't deploy memcache
    instances or previously opcoded cache files).

-- 
Morbus Iff ( cheese and rice saves )
Technical: http://www.oreillynet.com/pub/au/779
Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/
aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus