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@garfieldtech.com