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

[Luca Mandolesi]

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, <a.furieri at lqt.it> 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
> _______________________________________________
> Gfoss at lists.gfoss.it
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20141021/1076daf7/attachment.html>