<div dir="ltr">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.<div><br></div><div>Valuteremo le varie opzioni.</div><div><br></div><div><br></div><div>Grazie mille</div><div>Luca</div></div><div class="gmail_extra"><br><div class="gmail_quote">Il giorno 20 ottobre 2014 16:08,  <span dir="ltr"><<a href="mailto:a.furieri@lqt.it" target="_blank">a.furieri@lqt.it</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ciao Luca<span class=""><br>
<br>
On Mon, 20 Oct 2014 14:52:52 +0200, Luca Mandolesi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Salve a tutti,<br>
avrei bisogno di un consiglio dai più esperti di Spatialite.<br>
<br>
Ho un database che divulgo tramite il mio plugin pyarchinit.<br>
<br>
Alla prima installazione del plugin questo viene salvato sulla<br>
macchina e da lì in poi sarebbe auspicabile che il database venisse<br>
aggiornato con le nuove tabelle alfanumeriche, spaziali e relative<br>
viste che generiamo per aumentare le funzioni del plugin.<br>
<br>
Tuttavia Sandro Furieri consiglia sempre vivamente di utilizzare gli<br>
strumenti di spatialite_gui per lavorare sulle view... <br>
<br>
</blockquote>
<br></span>
"consiglia" (per quanto vivamente) non e' certo sinonimo di "obbliga" :-D<br>
la GUI non fa assolutamente nulla di magico; usa semplicemente<br>
costrutti SQL assolutamente standard.<br>
<br>
quel che e' assolutamente consigliato e' quindi che chi si avventura<br>
a scrivere codice SQL per proprio conto non vada avanti a colpi di<br>
fantasia (magari senza neppure leggere la doc), ma si assicuri sempre<br>
scrupolosamente di seguire fedelmente la strada canonica, cioe' proprio<br>
quella  riscontrabile e verificabile utilizzando gli strumenti standard<br>
offerti dalla GUI.<br>
<br>
magari nel dubbio leggersi il codice della gui per trarne utile<br>
fonte di ispirazione non sarebbe poi mai male ;-)<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Quindi mi chiedevo se è meglio che io usi delle query SQL dentro al<br>
plugin per aggiornare il DB e tutto ciò che mi serve è quello che si<br>
legge nel mitticoo spatailite cookbook, oppure dichiari che le<br>
versioni successive del mio DB saranno sempre incompatibili con le<br>
nuove e ogni volta esca con un DB nuovo.<br>
<br>
S'è capito? :)<br>
<br>
</blockquote>
<br></span>
mica tanto bene ;-)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Pareri?<br>
<br>
</blockquote>
<br>
provo a sintetizzare riformulando il quesito e cercando di dettagliare<br>
meglio lo scenario.<br>
<br>
se non capisco male, stiamo parlando di nuove funzionalita' interne<br>
al plug-in pyarchinit.<br>
evidentemente si prevede che verranno rilasciate successive versioni<br>
evolute e migliorate, e queste nuove versioni potrebbero aver bisogno<br>
di ulteriori tavole, viste, indici, triggers etc non presenti nella<br>
versione precedente.<br>
<br>
se e' cosi', ovviamente tocca a pyarchinit farsi carico del problema.<br>
immagino che la cosa migliore (e piu' apprezzata dagli utenti) potrebbe<br>
essere quella di distribuire degli strumenti automatici o semi-automatici<br>
in grado di effettuare la conversione dal vecchio al nuovo formato<br>
utilizzato dal DB.<br>
<br>
1) potrebbe trattarsi <a href="http://p.es" target="_blank">p.es</a>. di uno SQL script da lanciare dalla shell<br>
   (a mio gusto personale parrebbe la soluzione piu' opportuna)<br>
2) oppure potrebbe trattarsi di uno script python stand-alone.<br>
3) infine potrebbe anche trattarsi di un bottoncino nell'interfaccia<br>
   grafica del plug-in.<br>
   (temo sinceramente che l'epidemia di GUI-ite acuta ormai presente<br>
   in forma endemica spingera' purtroppo in questa direzione sventurata).<br>
<br>
giusto come parere personalissimo, eviterei di avventurarmi in operazioni<br>
di conversione "auto-magic" che non richiedono nessun intervento da parte<br>
dell'utenete.<br>
l'utente dovrebbe essere sempre ben consapevole di cosa avviene dietro<br>
alle quinte: specie quando (come in questo caso) potrebbe anche eventualmente<br>
trovarsi alla fine con un DB rovinato e non piu' funzionante nel caso<br>
malaugurato in cui qualcosa vada storto.<br>
<br>
comunque in linea di massima la cosa non pare affatto impossibile da<br>
realizzarsi, anzi addirittura c'e' un largo ventaglio di opzioni aperte.<br>
in ultima analisi basta semplicemente implementare qualche pezzo di SQL<br>
piu' o meno corposo scritto in modo appropriato.<br>
naturalmente serve anche testare minuziosamente il codice prima del<br>
rilascio pubblico, possibilmente su piu' piattaforme diverse (Win, Mac,<br>
almeno un paio di Linux diversi) e magari usando versioni diverse sia<br>
di SQLite che di SpatiaLite.<br>
<br>
per fare tutto questo non e' affatto indispensabile passare tramite la GUI;<br>
casomai quel che ha decisamente senso e' di utilizzare la GUI per mettere<br>
a punto i DB prototipali prima di iniziare lo sviluppo.<br>
cosi' come ha senso continuare ad utilizzare costantemente la GUI durante<br>
tutto l'intero ciclo di sviluppo come strumento di controllo e di verifica<br>
per accertarsi che non si stanno introducendo subdole smagliature che<br>
prima o poi andrebbero certamente a scapito di una corretta interoperabilita'.<br>
<br>
ciao Sandro<br>
______________________________<u></u>_________________<br>
<a href="mailto:Gfoss@lists.gfoss.it" target="_blank">Gfoss@lists.gfoss.it</a><br>
<a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss" target="_blank">http://lists.gfoss.it/cgi-bin/<u></u>mailman/listinfo/gfoss</a><br>
Questa e' una lista di discussione pubblica aperta a tutti.<br>
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.<br>
666+40 iscritti al 5.6.2014</blockquote></div><br></div>