[Gfoss] SQLite v.3.7.0

[a.furieri a lqt.it]

On Thu, 29 Jul 2010 07:59:07 +0200, Paolo Cavallini wrote
> qundi per SpatiaLite e RasterLite non cambia niente, a parte le 
> performances? Le API sono le stesse? 
>

API assolutamente identiche: non è cambiato neppure un peluzzo.

- by-default il DB viene creato "old style"
  N.B: in questa modalità può essere letto/scritto anche
  usando qualsiasi versione precedente di sqlite

- per attivare la modalità WAL occorre eseguire una direttiva:
  PRAGMA journal_file=wal
  * la direttiva è permanente (modifica l'header del DB)
  * se poi provi ad aprire un DB-WAL con una vecchia versione di
    SQLite esce immediatamente un errore fatale:
    "DB corrotto oppure criptato, impossibile accedere"

- per ripristinare la compatibilità a ritroso basta semplicemente
  aprire il DB con la 3.7.0 e lanciare:
  PRAGMA journal_file=delete

insomma, fare lo switching tra le due modalità è semplicissimo
e praticamente istantaneo.
direi che WAL è abbastanza più avido di risorse: occupa più
RAM, e genera dei logfiles più grossi.

ma il vantaggio enorme è che ora (con WAL) finalmente SQLite
supporta in modo decoroso la concorrenza degli accessi.

prima era praticamente impossibile fare lavorare due o più 
processi simultaneamente sul medesimo DB: prima o poi usciva
fuori il famigerato messaggio: 
"database is locked, transaction aborted"

ora invece (con WAL) *enne* processi possono accedere
simultaneamente in lettura senza interferenze: e 
contemporaneamenteun un unico processo può lavorare
tranquillamente in scrittura.
I dati inseriti/modificati/eliminati dal "processo scrittore" 
resteranno comunque invisibili per gli altri utenti fino a
quando la transazione non esegue il COMMIT.

Se poi serve assolutamente supportare due o più processi di 
scrittura concomitanti, allora sicuramente è il caso di passare 
a PostgreSQL :-)

Insomma, ora SQLite non è più ristretto al ruolo di "personal
DB" per usi strettamente desktop.
IMHO diventa più che ragionevole ipotizzare l'impiego di
SQLite (e SpatiaLite) p.es. anche in contesti WEB server,
dove tipicamente "si legge tanto" ma "si scrive pochino".

Penso in particolare ai server WFS / WFS-T, che parrebbero
fatti apposta per gestire un approccio basato su enne threads 
di lettura ed un unico thread di scrittura.

ciao Sandro