Drupal-SQLite

Please let our ADS show!

This sites offers only FREE software and it's supported by a few advertisement boxes (no intrusive popups).
Please:

  • disable your AdBlocker by adding CoolSoft website to whitelist
  • give the proper cookie consent
  • enable JavaScript for this website

This seconds wait is to let you update your browser configuration...

Ok, I've done the required changes... now show me your content!
!!! Please enable JavaScript !!!

Introduzione

Drupal-SQLite è un progetto per rendere Drupal funzionante con un database SQLite.

SQLite è un database leggero, veloce, di pubblico dominio e multipiattaforma.
E' usato da molti importanti progetti opensource; solo per nominarne uno: Mozilla Firefox.

Perchè ne ho bisogno?

Beh, molti hosting provider forniscono PHP 5.2 o successivi gratuitamente, mentre per avere un database MySQL è necessario pagare una (piccola) somma. Se ne vale la pena per siti medio grandi, con centinaia o migliaia di utenti, per siti medio-piccoli (come questo) un database MySQL è uno spreco.

Con Drupal-SQLite è possibile configurare rapidamente un sito Drupal che funzioni immediatamente non appena installato, dato che tutto il DB è contenuto in un singolo file.
Supponi di essere un theme designer o uno sviluppatore di moduli: puoi distribuire il tuo tema in un unico .zip o .tar.gz con un overhead di soli 1,5 Mb.

Questo thread mi ha dato la spinta per iniziare.
In questo lungo post diversi bravi sviluppatori si sono impegnati per aggiungere il supporto a SQLite per Drupal 4.7, 5 e quindi 6. Il thread è ora inattivo dato che la maggioranza di loro si è spostata alla versione 7 di Drupal, che avrà SQLite come cittadino di prima classe tra i DB supportati. Dato però che la transizione alla versione 7 richiederà diverso tempo, Drupal-SQLite può essere usato immediatamente come valida alternativa a Drupal 6.

Alternative

Esistono in rete diverse versioni di Drupal con supporto SQLite, ma nessuna di questa ha soddisfatto le mie aspettative.

Speedtech.it

(link attualmente disattivo)
Funzionante e basata su una verisone di Drupal 5.6 (vecchiotta) modificata per SQLite.

Pro:

  • funziona (questo sito l'ha usata fino a 6 mesi fa)

Contro:

  • è una versione 5.6 di Drupal, quindi un po vecchia
  • non usa i PDO, quindi il supporto ai DB SQLite è limitato alle versioni 2.x (che non sono così performanti come le 3.x)
  • non ci sono aggiornamenti da tempo

Siren

Profonda (forse troppo) patch a Drupal 6.x

Pro:

  • supporto ai PDO, quindi SQLite versione 3.x
  • altri database oltre a SQLite

Contro:

  • modifiche molto profonde al codice core di Drupal
    Dal sito ufficiale: "According to the needs of PDO and Oracle drivers implementation, ALL core queries and some APIs are hacked for compatibility concern."
  • anche se basato su Drupal (ver. 6.4) è ora completamente separato da esso; ciò significa che non potrete usare gli update di Drupal.

Drupal-SQLite

Ecco quindi i pro di Drupal-SQLite:

  • costruito su Drupal 6.10 (e successive, leggi punto seguente)
  • nessun core file modificato (eccetto uno, usato solo durante l'installazione: includes/install.inc.php) (*)
  • usa PDO (anche se l'originale Drupal non lo fa), quindi supporto a SQLite 3.x
  • supporta una gran numero di moduli e temi Drupal senza modifica

Drupal-SQLite è disponibile in due versioni:
- un archivio .zip pronto per essere scompattato nella radice del vostro server web
- un .patch file da applicare ai sorgenti di Drupal 6.x

Dopo aver installato la versione che preferite, aprite con il browser la pagina index.php del vostro nuovo sito Drupal e siete pronti ad iniziare.

(*) Drupal-SQLite modifica questo file per aggiungere alcune frasi di aiuto all'installazione con database SQLite. Dopo l'installazione questo file non è più usato quindi può essere tranquillamente sovrascritto da aggiornamenti successivi. Gli altri file modificati da Drupal-SQLite sono file aggiuntivi rispetto a Drupal standard.
Ciò significa che sarà possibile installare i successivi aggiornamenti ufficiali di Drupal senza "rompere" Drupal-SQLite.

Requisiti

Drupal-SQLite richiede PHP5 con il supporto PDO-SQLite abilitato.
Questo è fornito tramite l'estensione php_pdo_sqlite.dll(win) or php_pdo_sqlite.so(linux).

Per verificare che il supporto sia abilitato, create un file phpinfo.phpcontenente:

<?php phpinfo(); ?>

Aprite questo file nel browser e verificate che la sezione pdo_sqlite esista e sia abilitata.

NOTE to XAMPP users:
XAMPP 1.7.0 comes with pdo_sqlite disabled by default. To enable it:

  • open C:\xampp\apache\bin\php.inifile
  • find the row containing
    ;extension=php_pdo_sqlite.dll
  • remove the leading ;to enable PDO-SQLite
  • restart Apache

Come installare Drupal-SQLite

Scegliete il file da scaricare (in base alla soluzione di hosting e alle vostre preferenze):

  • Archivio ZIP
    Questa è la soluzione più "comoda", ed è la migliore sia per gli hosting su piattaforma Windows che per quelli su piattaforma Linux.
    L'archivio contiene la versione base di Drupal (indicata nel nome del file) già modificata per l'utilizzo di SQLite.
    Scaricate il file e scompattatelo nella cartella radice del vostro sito.
    Ora aprite con il browser il file install.php e seguite le istruzioni.
  • File .patch
    Dato che l'applicazione di file .patch su Windows non è proprio immediata, questa versione è dedicata agli utenti Linux esperti (ma anche Windows ovviamente).
    Scaricate il .patch file della versione Drupal che state per modificare, quindi applicate la patch al source-tree.

Ora aprite con il browser il file install.php e seguite le istruzioni, ricordando di:

  • selezionare il profilo Drupal-SQLite nella prima pagina, in modo da avere una configurazione ottimizzata
  • scegliere sqlite come "database type" nel blocco "basic options" della pagina successiva (purtroppo non c'è modo di forzare questa scelta attraverso il profilo)

Note di sicurezza

Il vostro database è ora un singolo file, per default sites/default/*.s3db.
Dovreste proteggere l'accesso a questo tipo di files per evitarne il download diretto.
Drupal-SQLite ha già preconfigurato nella cartella "sites/default" un file .htaccess per Apache che nega l'accesso a tutti i file *.s3db.
Se usate un file diverso oppure se non usate Apache, per favore proteggete questo fali dall'accesso esterno.

Moduli base

Drupal-SQLite fornisce un profilo di installazione (la prima pagina che appare durante l'install) che disabilita alcuni moduli base per funzionare più velocemente e ridurre il carico sul DB.
Questi moduli sono, ad esempio, dblog and syslog.
I moduli abilitati di default sono: 'color', 'comment', 'help', 'menu', 'taxonomy' e 'sqlitetools'.

Modulo sqlitetools

Dato che il database è ora un file singolo, è molto semplice farne un backup/restore tramite un semplice copia/incolla.
Per Drupal-SQLite ho creato il modulo sqlitetools (disponibile nell'area download) che permette di fare il backup del database corrente in un file ZIP e viceversa per il restore.
Sqlitetools permette inoltre di eseguire una pulizia del database (VACUUM) per liberare lo spazio inutilizzato.

Altri moduli aggiuntivi

Come detto Drupal-SQLite è una patch "non invasiva" a Drupal; per questo motivo dovrebbe funzionare correttamente con qualsiasi modulo che acceda al database tramite le funzioni di Drupal.
In alcuni casi particolari gli sviluppatori di moduli devono ricorrere a query SQL specifiche per il tipo di database attivo; per fare ciò solitamente includono un costrutto switch nel loro codice, come questo (dal modulo xmlsitemap):

switch ($GLOBALS['db_type']) {
    case 'mysql':
    case 'mysqli':
      $query .= "LEFT JOIN {url_alias} ua ON ua.src = ('node/' || '%d')";
      break;
    case 'pgsql':
      $query .= "LEFT JOIN {url_alias} ua ON ua.src = CONCAT('node/', CAST(%d AS VARCHAR))";
      break;
}

Come potete vedere una parte della query è composta diversamente in base al tipo di database attivo e, peggio ancora, non esiste un caso "default:" che metta almeno un errore nella pagina. Nel nostro caso $GLOBALS['db_type'] == 'sqlite', quindi nessun codice è eseguito e la query risulta essere incompleta.

Nell'esempio la soluzione è semplice:

switch ($GLOBALS['db_type']) {
    case 'mysql':
    case 'mysqli':
    case 'sqlite':
      $query .= "LEFT JOIN {url_alias} ua ON ua.src = ('node/' || '%d')";
      break;
    case 'pgsql':
      $query .= "LEFT JOIN {url_alias} ua ON ua.src = CONCAT('node/', CAST(%d AS VARCHAR))";
      break;
}

Come vedete il codice SQL è lo stesso di MySQL.

Il mio suggerimento è: prima di installare un modulo, cercate nei suoi sorgenti (grep per gli amici Linuxiani) la stringa 'mysql'o 'pgsql'e verificate che si tratti di un costrutto switch.
Se lo trovate, esaminate il codice e cercate di sistemarlo in modo che funzioni anche con SQLite; altrimenti mandate una segnalazione agli sviluppatori del modulo stesso.
Ok ok, so che potrebbero rispondervi che SQLite non è un database supportato (lo farei anche io ;) ), ma in molti casi il fix è molto semplice e si riduce a qualche riga.

Elenco moduli funzionanti

Per comodità ecco una lista di moduli dei quali posso confermare il funzionamento senza modifiche (molti di loro sono in uso in questo sito).
Se avete provato qualche modulo non listato, mandatemi il nome e la versione e li includerò in questa lista.

Modulo Versione Note
admin_menu 6.x-1.3  
blockquote 6.x-1.0  
captcha 6.x-1.0  
cck 6.4-2.4  
comment_notify 6.x-1.2  
devel 6.x-1.17 (vedi questo commento)
dhtml_menu 6.x-3.4  
fckeditor 6.x-2.0-alpha5  
geshifilter 6.x-1.2  
languageicons 6.x-1.1  
pathauto 6.x-2.x-dev  
permalink 6.x-1.1  
poormanscron 6.x-1.0  
potx (Translation Template Extractor) 6.x-3.0  
service_links 6.x-1.0  
taxonomy_dhtml 6.x-1.0-rc3  
token 6.x-1.11  
wysiwyg 6.x-2.0 + FCKeditor 2.6.4.1

Moduli non funzionanti

I moduli seguenti non funzionano immediatamente ma richiedono delle modifiche al codice.
Queste modifiche possono interessare poche linee (rilevanza=1) fino ad una importante riscrittura del modulo (rilevanza=5).

Modulo Versione Relevanza patch
date 6.x-2.3 5

Contributi e ringraziamenti

  • Guida all'installazione di Drupal-SQLite su Altervista (di Roberto Capuzzo, aka robocap)
    Guida pratica passo passo, completa di screenshots, per l'installazione di un sito Drupal-SQLite su spazio web Altervista.
    (ringrazio l'autore sia per la guida che per il permesso di pubblicarla)
  • Dmitri Schamschurko
    Grande aiuto nel debugging ed ottimizzazione nelle funzioni di modifica tabelle SQLite in database.sqlite.inc.
    Questo lavoro ha permesso il supporto del modulo CCK in Drupal-SQLite-6.13-1.2
Version history 

Drupal-SQLite-6.25-1.5, 2012-02-29

Drupal-SQLite-6.24-1.5, 2012-02-03

Drupal-SQLite-6.22-1.5, 2011-06-02

Drupal-SQLite-6.20-1.5, 2010-12-16

  • Drupal official version 6.20

Drupal-SQLite-6.19-1.5, 2010-08-12

Drupal-SQLite-6.17-1.5, 2010-06-03

  • Drupal official version 6.17

Drupal-SQLite-6.16-1.5, 2010-03-05

  • Drupal official version 6.16
    This release fixes security vulnerabilities.
    Sites are urged to upgrade immediately after reading the official security announcement:
    http://drupal.org/drupal-6.16

Drupal-SQLite-6.15-1.5, 2010-01-07

  • Drupal official version 6.15
  • Optimized query rewriting by adding shortcut returns after a successful rewrite.
  • New core rewrite rule for cache and update modules ("TRUNCATE TABLE" SQL commands).
  • Fixed an error during setup that causes install.php not use the values of "Site Name" and "Administrator username" fields. The default values were used instead.

Drupal-SQLite-6.14-1.4, 2009-10-04

  • Drupal official version 6.14
  • New query rewriting system: it allows Drupal-SQLite to rewrite SQL queries just before their execution, without the needing to patch (core) modules.
    Rewrite rules are contained into two new files:
    • database.sqlite.core-patches.inc
      this file is mantained by CoolSoft and will include rewrite rules for core modules and for widely used ones ;) (like devel)
    • database.sqlite.user-patches.inc (optional)
      here you could add rewrite rules for all other modules
  • Drupal DB functions "db_add_unique_key" and "db_remove_unique_key" are now supported.
  • Workaround for SQLite not returning short column names for queries with JOIN or GROUP BY clauses.
  • Added support for SQL function STDDEV (thanks again Dmitri)

Drupal-SQLite-6.13-1.3, 2009-08-06

  • Fixed a bug in _db_query function which caused multiple/nested queries to fail.

Drupal-SQLite-6.13-1.2, 2009-07-15

  • Bug fixing and code cleanup in SQLite table schema management functions: db_column_exists, db_create_table_sql, _db_create_index_sql,  _db_alterTable, _db_introspectSchema.
    Thanks to Dmitri Schamschurko for his great help and feedback.
  • CCK module (cck-6.4-2.4) now works with Drupal-SQLite.

Drupal-SQLite-6.13-1.1, 2009-07-02

  • Drupal official version 6.13, see here for detailed changes

Drupal-SQLite-6.12-1.1, 2009-05-14

  • Drupal official version 6.12

Drupal-SQLite-6.11-1.1.1, 2009-05-09

This is only a repackage of the previous archive version, due to missing folders in drupal-sqlite-6.11-1.1.zip file.
Missing folders were:

  • /modules/color/images
  • /sites
  • /themes/garland/images

I'm sorry for that <:)

Drupal-SQLite-6.11-1.1, 2009-05-05

Drupal-SQLite-6.10-1.0, 2009-03-21

  • Drupal official version 6.10
  • First public release

Download

Drupal-SQLite è presente su SourceForge all'indirizzo:
Get Drupal-SQLite at SourceForge.net. Fast, secure and Free Open Source software downloads http://sourceforge.net/projects/drupal-sqlite/

Le versioni di sviluppo sono accessbili tramite SVN, sempre su SourceForge, con il comando:
svn co https://drupal-sqlite.svn.sourceforge.net/svnroot/drupal-sqlite/trunk drupal-sqlite

drupal-sqlite-6.25-1.5.tar.gz
Descrizione Fully patched version (compressed TAR archive)
Release date 2012-Feb-29 Dimensione 1,082,929 bytes
MD5 6bec33f490823b60e928e6a7900a5b16
SHA1 db7c79203c0ab277356863cbd551646ecefaf7fb
SHA256 63f4c6710cc3fd87458862a879520935c4087365cb181838943f876f28593caa
Open virus check report
drupal-sqlite-6.25-1.5.zip
Descrizione Fully patched version (compressed ZIP archive)
Release date 2012-Feb-29 Dimensione 1,280,368 bytes
MD5 ab988f79fcc70682c111fedcd06c598d
SHA1 080b96b249ae57924feff73741b816c42a1bc07d
SHA256 1df6ccd3bb4fc69cc638ecdd1dffaf090dead3d48e0bb30359051db01d9939df
Open virus check report
drupal-sqlite-6.25-1.5.diff
Descrizione Patch file for Drupal sources
Release date 2012-Feb-29 Dimensione 72,496 bytes
MD5 6fff775f01125f3a206a32b99e4b9447
SHA1 944fe43f9f9e0376d2c5714525bc9f41b8ec62da
SHA256 7d61d8c6aaa832b5fa19013216c62c0b0d45b59deda14b3cf174e577a3e545e1
Open virus check report
sqlitetools-6.x-1.1.tar.gz
Descrizione sqlitetools module (compressed TAR archive)
Release date 2009-Maggio-05 Dimensione 54,803 bytes
MD5 5f6ef9d960a8e3d8a7e39ea8034c64cb
SHA1 1f5244d040a8cad02d95cde7389b918ab6887640
SHA256 67fddb3e965fb62a887e7da697ae6f6e79d1d3668f8b4fb99eb48afb62d8e804
Open virus check report
sqlitetools-6.x-1.1.zip
Descrizione sqlitetools module (compressed ZIP archive)
Release date 2009-Maggio-05 Dimensione 56,937 bytes
MD5 92b61dad1c29e4700526435c90bcb04f
SHA1 7eb1867f2f8cc4692e20e6ef558f087fd2cfe459
SHA256 9dffc2fe97d18d63614dd6659866de471b1f9528a94d1c514ddd957373aa77c6
Open virus check report
Installazione_Drupal-SQLite_su_Altervista.pdf
Descrizione Istruzioni per linstallazione su www.altervista.org
Release date 2009-Lug-16 Dimensione 173,765 bytes
MD5 fcad99e64318d1826917fe1f2c3ad779
SHA1 b3a0c82ca37399ee09d6d508963564beedfb1da4
SHA256 5d6d36cdd580a10957c17fa66108635f372dc4c77aeaa444a7426999f63279cd
Open virus check report

Commenti

Pagine

EDIT: the discussion continued privately. I reported here only relevant parts.

Hi pm530,
I need further info about your issue...

- does the user appear in users table inside database file?
  You can use a SQLite database manager to open it, like this plugin for Firefox: sqlite-manager (http://code.google.com/p/sqlite-manager)
- can you login with created users? If yes, it could be a theme issue: what's yours?
- which modules (core and additional) are enabled?

As a last chance, create a new and clean site, with no additional modules enabled.
Add a new user (after the admin) and retry.
If the bug persists, make a compressed archive of this site DB and send it to me; I'll give it a try ASAP.

Waiting for your feedback.

Hi Claudio
1. You are cool.
2. The records are written into the db file.
3. Newly created users can login.
4. I can see only one user (Anonymous) in admin/user/user.
5. This happens in a new and clean installation.

The linux box is:
lighttpd/1.4.20
SQLite Library 3.6.2
php 5.29

Hi pm530,
sorry for the late reply but today and tomorrow is holiday here in Italy, so I read email less frequently.

Your DB loaded perfectly in my setup and all the users I create appear in the users list.
There's a thing I first noticed in the screenshot you sent me: the Administrator user was created 39 years ago!!!
This could be due to a problem with date on your Lighttpd/PHP/SQLite environment.

Is this the first PHP application you installed or are there any other working correctly?
Sorry for not having better ideas...

Sorry for the late reply.
Thank you again for you kindness. The user listed in the screenshot is actually anonymous, not administrator.
I think I've nailed down the problem: after upgrading the sqlite library from 3.6.2 to 3.6.14, the problem is gone :) .

Glad you sorted it out and thanks for sharing your knowledge with other users ;)

Let me know your new website URL when done.

Hello Claudio,
Thanks a lot for your efforts developing the Drupal sqlite.

I have been trying to install your Drupal-sqlite, but as I get the second installation page in which I have to: "select sqlite as database type inside the "basic options" block (I can't find a way to force this selection through the profile)" this "sqlite" option doesn't appear.

I would appreciate if you may help me to continue.
Thanks Carlos

It seems you are missing PDO-SQlite support in your PHP configuration.

Maybe my documentation should be clearer about the requirements:
Drupal-SQLite works with PDO database layer, then you need to enable PDO-SQLite support in your PHP.

Try to create a phpinfo page, then look for a section named pdo_sqlite.

Post me your results through the Contact form and I'll be glad to help you.

SOLVED: The problem was XAMPP, which comes with PDO-SQLite disabled by default.
I added system requirements to this page, helping XAMPP users to enable PDO-SQLite support.

I'm tryng to setup SEND module with SEND FRIEND module and MIME.

In the page http://...../node/x/send nothing work and this is the error:

  • warning: PDO::prepare() [pdo.prepare]: SQLSTATE[HY000]: General error: 1 near ".": syntax error in /Applications/MAMP/htdocs/druzip/includes/database.sqlite.inc on line 218.
  • user warning: near ".": syntax error
    query: SELECT COUNT(*) FROM (SELECT send.sid AS sid FROM send send WHERE .nid = 4 ) count_alias in /Applications/MAMP/htdocs/druzip/sites/all/modules/views/includes/view.inc on line 739.
  • warning: PDO::prepare() [pdo.prepare]: SQLSTATE[HY000]: General error: 1 near ".": syntax error in /Applications/MAMP/htdocs/druzip/includes/database.sqlite.inc on line 218.
  • user warning: near ".": syntax error
    query: SELECT send.sid AS sid, send.timestamp AS send_timestamp, name, uid, send.subject AS send_subject, send.message AS send_message FROM send send WHERE .nid = 4 LIMIT 20 OFFSET 0 in /Applications/MAMP/htdocs/druzip/sites/all/modules/views/includes/view.inc on line 765.

How i can correct?

Thanks!

Could you please post the relevant parts of phpinfo() output?

tnx for quick reply.

how can i do that? (one time i force drupal to see all php errors but white page again..)

the problem is when database file is about 4mb then another file appear in same folder with .journal extension. site is all white pages then. is any filesize limit in sqlite?

the sites is from my lab in my university in expirimental state.. im student here and we try to not invole mysql...

i must figure out if is host site issue or sqlite issue (shall i try Xammp?)

tnx so much for your time and for you answers!!

See in the "Requirements" section above, where I describe the procedure to create a phpinfo.php file.

SQLite is not limited, and 4Mb is too low to be an acceptable limit! This site database is more than 30Mb, so that's not the culprit.
What's the host config (I mean OS, PHP, ...)?
Have you double checked the database folder permissions? Web Server must have RW on both the database file AND the containing folder.
Is the temporary folder set and available, with sufficient disk space? (you can retrieve all these info through the phpinfo file).

As for XAMPP, yes you can test it and it works perfectly; please ensure that the XAMPP user has RW permissions on Drupal folders.

Send me the phpinfo() file once you have it, using the contact form.

Thank you for Drupal-SQLite! Very handy!
But there are a few erros in Backend, after successful installation.
It starts with:
warning: PDOStatement::execute() [function.PDOStatement-execute]: SQLSTATE[HY000]:
General error: 14 unable to open database file in /var/www/drupal-sqlite/includes/database.sqlite.inc on line 214.
# user warning: query: UPDATE variable SET value = 'b:0;' WHERE name = 'drupal_http_request_fails' in /var/www/drupal-sqlite/includes/bootstrap.inc on line 519.
# warning: PDOStatement::execute() [function.PDOStatement-execute]: SQLSTATE[HY000]: General error: 14 unable to open database file in /var/www/drupal-sqlite/includes/database.sqlite.inc on line 214.

sqlite-file ist read- and writeable by webserver.
Webserver lighttp PHP Version 5.2.4-2ubuntu5.5
Any Ideas?
Regards Jehu

Really don't know.
It seems it can't write (I saw the error comes from an UPDATE SQL command) but you said you checked read/write permissions of *.s3db file...

I'll write you an email so we could solve it privately, then I'll post the final solution here.
Stay tuned.

Tnx for your mail and hints, coolsoft.
I've found this (http://www.mail-archive.com/[email protected]/msg28190.html) and now I also know that the directory need write permissions too...

Thanks again.
You've done a good Job with Drupal-SQLite!

I'm glad we sorted it out.
I'll add a note in setup instructions for the upcoming next version and, better, will perform a test while creating the database file.

Let me know when your website will be on-line and I'll post here.

Hi, To further on the permission problems, --- putting the db.s3db in a seperarte folder, (I created a folder called db in the main directory) stopped the many errors I got after installing. It seems drupal keeps setting permission of the ./sites/default/ directory to non writable, but in my case it needs to be writable to write to the sqlite db file (on linux running apache). During the last step of the install and afterwards it kept producing errors on writing to the database.

This is my first time on drupal after a few years away, and first time testing it with sqlite, so please let me know if you can think of any issues with creating a db folder with owner write permissions like I have.

--Vince

Hi Vince, let me explain this issue a little bit for all the audience ;)

SQLite needs RW on the folder containing the DB because, during its life, it sometimes needs to create additional temporary and journal files.
That said, RW on the *.s3db is mandatory to be able to change it with INSERT, DELETE and UPDATE queries; but when transactions get into the game (like bunch of INSERTS and/or UPDATES), SQLite needs temp files support. Because of this, RW on the *.s3db file itself is not enough and the file creation permission is needed (RW on the folder).

What you suggest (a separate folder for the db) is what I'm trying to do in next Drupal-SQLite version.
It'll be safer to require RW on a folder which contains only the database and not (actually) other relevant ones like settings.php.
This will also make easier to fix the security issue regarding the db file being downloaded: an .htaccess file which denies access to all will suffice.

As for your question, I can't see any issue having a folder with RW permissions (many PHP applications have it), except creating it in website root.
Drupal suggested folders are under sites/ folder (see api.drupal.org/api/file/sites/default/settings.php/5), so I'll suggest to choose one of these.

Stay tuned and subscribe to the newsletter to be informed about new releases.

Thanks for your comment
Claudio

Hello Claudio,

Thanks a lot for the sqlite3 patch for Drupal 6, which I have been waiting for quite some time.
I have just finally managed to use SQLite for my test web site, but I always get the following error messages on my lighttpd error log:

2009-04-23 19:43:10: (mod_fastcgi.c.2610)
FastCGI-stderr:
PHP Notice: Undefined variable:
username in /home/www/drupal-6.10_SQLite/includes/database.sqlite.inc on line 82
PHP Notice: Undefined variable:
password in /home/www/drupal-6.10_SQLite/includes/database.sqlite.inc on line 82

So what I changed that line 82 on database.sqlite.inc from:

$connection = new PDO($dsn, $username, $password, $driver_options);

to

$connection = new PDO($dsn, '', '', $driver_options);

There is now no such error as before.

Thanks again.
Anto

Thanks for your fix, Anto.

I missed this; I'll be included it in the upcoming version.
And I will set my PHP to show warnings ASAP ;).

I commenti nella versione inglese di questa pagina sono piu' numerosi e riguardano problemi (e relative soluzioni) che si possono verificare durante l'installazione e l'uso di Drupal-SQLite.
Li potete trovare a questo indirizzo.

I noticed that comments on this page were accidentally closed for a few days.
Sorry for that...

I've installed the latest version. Everything looks fine. But I cannot add users ( Users can be added, but doesn't show on the user list).
Please give me a clue.

I've just set up this version of Drupal SQLite v6.12 on very low-memory (360MB) machine running nginx+fastcgi.  Very noticeable increase in page loads.

Is there still a performance benefit from page caching with the SQLite database layer?  Since cached content is stored in the database, caching would presumably cause the database flat file to grow in size substantially, and possiblity negate the desired effect of the caching.

IMHO page caching is mandatory for each website, even those hosted on a super quad-core machine.
That's because I hate redoing the same thing I've already done 10 seconds ago :)

Think of a Drupal page life cycle: request parsing, user auth, modules activation and invocation, content retrieval for node and all of the modules|menus|links|comments, layout composition & rendering, compression.
Moreover most of these steps require a DB query.

Content caching requires only a DB query to retrieve the already compressed result, if still valid.
My suggestion is to enable caching, since it always worth.

As for the DB space,I don't know what kind of site you're building; just to give a reference, the database of this site is near 20Mb uncompressed.

 

Hi!

I am really glad that you've done this port of drupal. It really works well, even with modules other than listed here. So far I've only had one problem with the devel module. It fails with an SQL error (on the devel_query table) upon install.

I have tried devel-6.x-1.17 and it will probably be the same with later versions as well. It is only the devel / devel module that's affected.
The fix is simple though: just open up the devel.install file from the module's directory, and change in the devel_schema() function this:

'primary key' => array('qid'), 
'indexes' => array('hash' => array('hash'))

Easy, not? ;)

When you uninstall the devel module - it might still say errors about database table being locked. Do not worry, if all else fails, and you really want to get rid of the devel tables, just open up the database from your favorite editor and droip the devel_* tables.

Thanks for your tip and effort providing a workaround...

Hi, I'm trying to set up a calendar style view on drupal-sqlite but always get an error related to a wrong query. Once I setup the view, the list shows the following error:

  • warning: PDO::prepare() [pdo.prepare]: SQLSTATE[HY000]: General error: 1 near "<=": syntax error in C:optApache2htdocsdrupal-sqliteincludesdatabase.sqlite.inc on line 195.

  • user warning: near "<=": syntax error
    query: SELECT node.nid AS nid, node.title AS node_title, node_data_field_date.field_date_value AS node_data_field_date_field_date_value, node_data_field_date.field_date_value2 AS node_data_field_date_field_date_value2, node_data_field_date.field_date_rrule AS node_data_field_date_field_date_rrule, node_data_field_date.delta AS node_data_field_date_delta, node.type AS node_type, node.vid AS node_vid FROM node node LEFT JOIN content_field_date node_data_field_date ON node.vid = node_data_field_date.vid WHERE ( <= '2009-08' AND >= '2009-08') in C:optApache2htdocsdrupal-sqlitemodulesviews-6.x.3.x-devviewspluginsviews_plugin_query_default.inc on line 1094.

As you can see, the column that should have been passed on as argument is ommitted! WHERE ( <= '2009-08' AND >= '2009-08'). As I've have not found this issue in any other drupal related websites I supposed it is related to your patch. Am I right? I'm using the following versions:
- Windows XP
- SQLite3
- Drupal-SQLite 6.13-1.3
  -> views-6.x.3.x-dev
  -> calendar-6.x.2.2
  -> cck-6.x.2.5
  -> date-6.x.2.3

Hi Davyd, I have bad news for you.
As I said, not all of Drupal modules will work, and Date is one of them.

I setup an environment like yours and I see that Date module is not SQLite aware at all.
A quich search for 'mysql' string returned a bunch of results from the Date module.
File date/date_api_sql.inc contains a lot of switch constructs due to the fact it is strictly DB-related.

Example, at line 10:

function date_sql_concat($array) {
  global $db_type;
  switch ($db_type) {
    case('mysql'):
    case('mysqli'):
      return "CONCAT(". implode(",", $array) .")";
    case('pgsql'):
      return implode(" || ", $array);
  }
}

This code is easily patchable to make it work with SQLite:

function date_sql_concat($array) {
  global $db_type;
  switch ($db_type) {
    case('mysql'):
    case('mysqli'):
      return "CONCAT(". implode(",", $array) .")";
    case('sqlite'):
    case('pgsql'):
      return implode(" || ", $array);
  }
}

This is the easiest one, other functions are harder.
See sql_field() at line 163, which requires deep changes and, maybe, missing SQLite SQL functions to be added.

I think that making Date module work with Drupal-SQLite is not feasible.
Sorry.

Hi Davyd,

I had the same problem two months ago on my site.
As Claudio already said, the Date module needs a lot of patches. In almost every function you have a
switch ($db_type) {

Here my patch file for date/date_api_sql.inc.
It is by far not perfect, but it works for me, may be also for you.

--- date_api_sql.orig.inc	So Mai  3 17:37:16 2009
+++ date_api_sql.inc	Di Jul 14 20:58:37 2009
@@ -14,6 +14,7 @@
     case('mysqli'):
       return "CONCAT(". implode(",", $array) .")";
     case('pgsql'):
+    case('sqlite'):
       return implode(" || ", $array);
   }
 }
@@ -30,6 +31,7 @@
     case('mysql'):
     case('mysqli'):
     case('pgsql'):
+    case('sqlite'):
       return "COALESCE(". implode(',', $array) .")";
   }  
 }
@@ -97,7 +99,10 @@
           if ($test == '2008-02-15 06:00:00') {
             $has_support = TRUE;
           }
-        break;
+          break;
+        case('sqlite'):
+          // no support
+          break;
       }
       variable_set('date_db_tz_support', $has_support);
     }
@@ -130,6 +135,9 @@
       elseif ($type == 'pgsql') {
         db_query("SET TIME ZONE INTERVAL '$offset' HOUR TO MINUTE");
       }
+      elseif ($type == 'sqlite') {
+        // no support
+      }
       $already_set = true;
     }
   }
@@ -185,6 +193,18 @@
             break;
         }
         break;
+      case('sqlite'):
+        switch ($this->date_type) {
+          case DATE_UNIX:
+            $field = "FROM_UNIXTIME($field)";
+            break;
+          case DATE_ISO:
+            $field = "REPLACE($field, 'T', ' ')";
+            break;
+          case DATE_DATETIME:
+            break;
+        }
+        break;
       case 'pgsql':
         switch ($this->date_type) {
           case DATE_UNIX:
@@ -216,6 +236,17 @@
           else {
             return "DATE_ADD($field, INTERVAL $offset SECOND)";
           }
+        case('sqlite'):
+          $offset = ($offset >= 0) ? "+ $offset" : ("- " . -$offset);
+          switch ($this->date_type) {
+            case DATE_UNIX:
+              return "($field $offset)";
+            case DATE_ISO:
+              return "STRFTIME('%Y-%m-%%dT%H:%M:%S', $field, '$offset SECONDS')";
+            case DATE_DATETIME:
+              return "DATETIME($field, '$offset SECONDS')";
+          }
+          break;
         case 'pgsql':
           return "($field + INTERVAL '$offset SECONDS')";;
       }
@@ -247,6 +278,16 @@
           case 'SUB':
             return "DATE_SUB($field, INTERVAL $count $granularity)";
           }
+      case('sqlite'):
+        $direction = ($direction == 'ADD') ? '+' : '-';
+        switch ($this->date_type) {
+          case DATE_UNIX:
+            return "STRFTIME('s', $field, '$direction $count $granularity')";
+          case DATE_ISO:
+            return "STRFTIME('%Y-%m-%%dT%H:%M:%S', $field, '$direction $count $granularity')";
+          case DATE_DATETIME:
+            return "DATETIME($field, '$direction $count $granularity')";
+        }
 
       case 'pgsql':
         $granularity .= 'S';
@@ -307,6 +348,8 @@
           // WITH TIME ZONE assumes the date is using the system
           // timezone, which should have been set to UTC.
           return "TIMESTAMP WITH TIME ZONE $field AT TIME ZONE $localzone";
+        case 'sqlite':
+          // no support
       }
     }
   }
@@ -336,6 +379,18 @@
           );
         $format = strtr($format, $replace);
         return "DATE_FORMAT($field, '$format')";
+      case('sqlite'):
+        $replace = array(
+          'Y' => '%Y', 'y' => '%y',
+          'm' => '%m', 'n' => '%c',
+          'd' => '%%d', 'j' => '%j',
+          'H' => '%H',
+          'i' => '%M',
+          's' => '%S',
+          'WW' => '%W',
+          );
+        $format = strtr($format, $replace);
+        return "STRFTIME('$format', $field)";
       case 'pgsql':
         $replace = array(
           'Y' => 'YYYY', 'y' => 'Y',
@@ -387,6 +442,7 @@
           // WEEK using arg 3 in mysql should return the same value as postgres EXTRACT
           return "WEEK($field, 3)";
         case('pgsql'):
+        case('sqlite'):
           return "EXTRACT(WEEK FROM($field))";
       }
     case('DOW'):
@@ -397,6 +453,7 @@
           // php date functions and postgres use 0 for Sunday and 6 for Saturday
           return "INTEGER(DAYOFWEEK($field) - 1)";
         case('pgsql'):
+        case('sqlite'):
           return "EXTRACT(DOW FROM($field))";
       }
     case('DOY'):
@@ -405,6 +462,7 @@
         case('mysqli'):
           return "DAYOFYEAR($field)";
         case('pgsql'):
+        case('sqlite'):
           return "EXTRACT(DOY FROM($field))";
       }
     }

Thanks Dmitri for your patch and for all the other valuable ones you sent me before (see changelog).
A new forum will start soon: this way searching for issues and patches will be easier.

Pagine