[Gfoss] SQLite v.3.7.0

[G. Allegri]

Ciao Sandro,
grazie per l'ottima review. Mi fa piacere vedere tanta evoluzione in
Sqlite, e la necessità di qualcosa simil-WAL era proprio sentita... e
vedere che hanno implementato proprio WAL va oltre le aspettative! :)
Domanda (non so se mi sono perso qualche passaggio): quando pensi di
rendere disponibile Spatialite su Sqlite 3.7?

giovanni

Il 29 luglio 2010 09.15,  <a.furieri a lqt.it> ha scritto:
> 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
>
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> Gfoss a faunalia.it
> http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non rispecchiano necessariamente
> le posizioni dell'Associazione GFOSS.it.
> 460 iscritti al 15.7.2010
>