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, <[email protected]> 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 > [email protected] > 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 > _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] 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
