[Gfoss] DB spatialite: come gestire un aggiornamento di tabelle e view rilascio di versioni aggiornate

[a.furieri a lqt.it]

ciao Luca

On Mon, 20 Oct 2014 14:52:52 +0200, Luca Mandolesi wrote:
> Salve a tutti,
> avrei bisogno di un consiglio dai più esperti di Spatialite.
>
> Ho un database che divulgo tramite il mio plugin pyarchinit.
>
> Alla prima installazione del plugin questo viene salvato sulla
> macchina e da lì in poi sarebbe auspicabile che il database venisse
> aggiornato con le nuove tabelle alfanumeriche, spaziali e relative
> viste che generiamo per aumentare le funzioni del plugin.
>
> Tuttavia Sandro Furieri consiglia sempre vivamente di utilizzare gli
> strumenti di spatialite_gui per lavorare sulle view... 
>

"consiglia" (per quanto vivamente) non e' certo sinonimo di "obbliga" 
:-D
la GUI non fa assolutamente nulla di magico; usa semplicemente
costrutti SQL assolutamente standard.

quel che e' assolutamente consigliato e' quindi che chi si avventura
a scrivere codice SQL per proprio conto non vada avanti a colpi di
fantasia (magari senza neppure leggere la doc), ma si assicuri sempre
scrupolosamente di seguire fedelmente la strada canonica, cioe' proprio
quella  riscontrabile e verificabile utilizzando gli strumenti standard
offerti dalla GUI.

magari nel dubbio leggersi il codice della gui per trarne utile
fonte di ispirazione non sarebbe poi mai male ;-)


> Quindi mi chiedevo se è meglio che io usi delle query SQL dentro al
> plugin per aggiornare il DB e tutto ciò che mi serve è quello che si
> legge nel mitticoo spatailite cookbook, oppure dichiari che le
> versioni successive del mio DB saranno sempre incompatibili con le
> nuove e ogni volta esca con un DB nuovo.
>
> S'è capito? :)
>

mica tanto bene ;-)

> Pareri?
>

provo a sintetizzare riformulando il quesito e cercando di dettagliare
meglio lo scenario.

se non capisco male, stiamo parlando di nuove funzionalita' interne
al plug-in pyarchinit.
evidentemente si prevede che verranno rilasciate successive versioni
evolute e migliorate, e queste nuove versioni potrebbero aver bisogno
di ulteriori tavole, viste, indici, triggers etc non presenti nella
versione precedente.

se e' cosi', ovviamente tocca a pyarchinit farsi carico del problema.
immagino che la cosa migliore (e piu' apprezzata dagli utenti) potrebbe
essere quella di distribuire degli strumenti automatici o 
semi-automatici
in grado di effettuare la conversione dal vecchio al nuovo formato
utilizzato dal DB.

1) potrebbe trattarsi p.es. di uno SQL script da lanciare dalla shell
    (a mio gusto personale parrebbe la soluzione piu' opportuna)
2) oppure potrebbe trattarsi di uno script python stand-alone.
3) infine potrebbe anche trattarsi di un bottoncino nell'interfaccia
    grafica del plug-in.
    (temo sinceramente che l'epidemia di GUI-ite acuta ormai presente
    in forma endemica spingera' purtroppo in questa direzione 
sventurata).

giusto come parere personalissimo, eviterei di avventurarmi in 
operazioni
di conversione "auto-magic" che non richiedono nessun intervento da 
parte
dell'utenete.
l'utente dovrebbe essere sempre ben consapevole di cosa avviene dietro
alle quinte: specie quando (come in questo caso) potrebbe anche 
eventualmente
trovarsi alla fine con un DB rovinato e non piu' funzionante nel caso
malaugurato in cui qualcosa vada storto.

comunque in linea di massima la cosa non pare affatto impossibile da
realizzarsi, anzi addirittura c'e' un largo ventaglio di opzioni 
aperte.
in ultima analisi basta semplicemente implementare qualche pezzo di SQL
piu' o meno corposo scritto in modo appropriato.
naturalmente serve anche testare minuziosamente il codice prima del
rilascio pubblico, possibilmente su piu' piattaforme diverse (Win, Mac,
almeno un paio di Linux diversi) e magari usando versioni diverse sia
di SQLite che di SpatiaLite.

per fare tutto questo non e' affatto indispensabile passare tramite la 
GUI;
casomai quel che ha decisamente senso e' di utilizzare la GUI per 
mettere
a punto i DB prototipali prima di iniziare lo sviluppo.
cosi' come ha senso continuare ad utilizzare costantemente la GUI 
durante
tutto l'intero ciclo di sviluppo come strumento di controllo e di 
verifica
per accertarsi che non si stanno introducendo subdole smagliature che
prima o poi andrebbero certamente a scapito di una corretta 
interoperabilita'.

ciao Sandro