[development] SQLite and Drupal 7

[Larry Garfield]

On Monday 02 February 2009 10:14:02 pm Karoly Negyesi wrote:

> Questions are
>
> 1) Are we OK with making Drupal rely on SQLite for every request?

No.

> 2) Do we want "deploy your SQLite table and be done"?

I don't get what this means exactly, so I will say no. :-)

> 3) Do we want table versions?

Seems like a lot of extra tracking we don't want to have to deal with.

> 4) Should I just shut up and go back into my corner?

Of course not. :-P

For those playing our home game, the approach that I have been envisioning 
here has been to, as chx alludes to above, introduce a "clone table" operation 
within the DB layer.  The implementation shouldn't be overly complex; it's 
just a select, multi-insert, delete, execute multi-insert.  (Give or take some 
performance tuning.)  The race condition window would be quite small.

Then on certain operations, particularly things like menu rebuild or registry 
rebuild, after the main DB table is rebuilt we check if there is a "system" 
target defined and if so, run the clone table operation from the "default" 
target to the "system" target.  (Probably that would be checked within the 
clone method on the database layer itself, which internally becomes a no-op if 
the target is not defined.)  The "system" target then *need not be SQLite*.  It 
could be any supported database, on whatever system.  Optimize your site as 
needed.

We then set queries that rely just on those tables to use the the "system" 
target.  If it's defined, it gets used.  If not, the default database still has 
all of the data so the query falls back to that and everything keeps working.

-- 
Larry Garfield
larry at garfieldtech.com