Hi, I think the main issue here is that chx is viewing things from the side of a Drupal Core developer while others are seeing it from the side of a user. The users don't particularly care that the code that bootstraps Drupal is nice (although they propably should!) so are mostly concerned about what's in it for them... 1. If I am a new Drupal user that just wants to install the thing and do usual stuff will this SQLite issue ever cross my radar? Will I notice it exists? (let's assume that my host setup supports it and I don't have to change anything myself) 2. If I am a web developer putting together Drupal sites everyday will this help me put them together sites any faster? 3. Will it help me save a site if a user messes things up? Will it help with upgrading to a new version of Drupal? 4. Will I need to touch it when I add or remove a module? If this affects ends users (in that it makes things more complex) then it needs to be seriously considered and it has a lot going against it. If it does not affect end users but makes the core code nicer and easier to handle then it has a lot going for it. One last note, anything that could make deploying a Drupal profile easier with the profile being as completely set-up as possible would be a huge bonus for Drupal. Best, Ronald Karoly Negyesi 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