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

[mando]

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... 

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? :)

Pareri?

Ciao

Luca

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[a.furieri]

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
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[mando]

Grazie Alessandro delle dritte fondamentali...tuttavia mi sono accorto che devo non solo aggiungere campi, ma addirittura fare dei drop view e rigenerare le view stesse....diventa tutto molto complesso quando a decidere la struttura dei dati non sei tu.

Valuteremo le varie opzioni.

Grazie mille

Luca

Il giorno 20 ottobre 2014 16:08, <[hidden email]> ha scritto:

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
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[a.furieri]

On Tue, 21 Oct 2014 15:25:41 +0200, Luca Mandolesi wrote:
> Grazie Alessandro delle dritte fondamentali...tuttavia mi sono
> accorto
> che devo non solo aggiungere campi, ma addirittura fare dei drop view
> e rigenerare le view stesse....diventa tutto molto complesso quando a
> decidere la struttura dei dati non sei tu.
>

Luca,

quella frasettina "quando a decidere la struttura dei dati non sei tu"
mi fa nascere dubbi angosciosi e decisamente inquietanti.

ma stiamo parlando solo ed esclusivamente della struttura delle tavole
interne definite da pyarchinit ?
oppure quando parli di problemi di versioni successive intendi toccare
direttamente anche le meta-tavole interne di SpatiaLite ?

la risposta che ho gia' dato vale ovviamente solo ed esclusivamente per
l'aggiornamento tra versioni successive di pyarchinit; ma in questo
caso ovviamente sei proprio tu a decidere tutto dall'A alla Z

se invece parliamo delle tavole di sistema di SpatiaLite la risposta
e' totalmente differente:

A) evitare sempre e comunque qualsiasi tentazione di interferire usando
    strumenti che non siano quelli "vanilla" offerti da spatialite;
    finira' sicuramente malissimo.

B) non vi e' nessuna reale necessita' di modificare il layuout delle
    meta-taavole interne di spatialite: qualsiasi versione successiva e'
    sempre perfettamente in grado di leggere e scrivere i DB-files
    creati da qualsiasi versione precedente, e lo fa in modo
assolutamente
    trasparente.
    per capirsi meglio: quando apri con la 4.2 un DB creato con la 3.0
    la 4.2. si comporta esattamente come si sarebbe comportata la 3.0,
    quindi non avrai mai problemi di back-compatibility.
    ovviamente non vale nel senso opporto: di norma la 3.0 non riuscira'
    ad aprire correttamente un DB creato dalla 4.2
    l'evoluzione e' sempre una strada a senso unico: si va sempre in
    avanti e non si torna mai indietro.

C) esiste comunque un tool a riga di comando che consente di cambiare
    al volo il formato interno di un DB gia' esistente:
          spatialite_convert (lo trovi tra gli spatialite-tools)
    dai ritorni di esperienza pratica pare robusto ed affidabile;
    funziona in entrambi i sensi: puoi ottenere un DB 4.x a partire da
    uno 3.x, ma puoi anche ottenere un 3.x a partire da un 4.x

ciao Sandro

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[mando]

CIao Alessandro, mi riferivo a pyarchinit e alla disciplina archeologica, che ad ogni angolo cambia modo di schedare i propri oggetti...e quindi è tutto un andirivieni di update, modifiche ecc di tabelle...campi...view...un stress infinito...per esempio un'area di scavo c'è chi la chiama settore, chi usa lettere, chi numeri obbligatoriamente a minimo 4 cifre (es. 1000) oppure a un numero solo...

Magari fosse tutto bello come sqlite! Cmq grazie per la mini lezione!

:)

Luca

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014