On Tue, 18 Nov 2014 09:25:45 +0100, Luca Lanteri wrote:
test 2)
-------
sqlite3 pippo2.sqlite
SELECT load_extension('mod_spatialite');
SELECT InitSpatialMetadata(1, 'WGS84');
.quit
questa invece e' l'inizializzazione "leggera"; dentro a
"spatial_ref_sys"
ci finiscono solo 130 righe, cioe' tutta la famiglia WGS84: 4326 +
tutti
i fusi dal 32601 fino al 32766.
size: 256 KB
Bella questa, no la conoscevo !
Io in genere creo i db da spatialite-gui. Posso creare un DB con
tutti
i SR e poi eliminare quelli che non mi servono o in questo modo si
crea qualche problema ?
certo che puoi eliminare tutti i CRS che non utilizzi e che non
prevedi di utilizzare mai.
in fondo l'effetto e' sempre il medesimo: sia che tu applichi una
"inizializzazione leggera" tanto che tu faccia la classica
"inizializzazione completa" e poi elimini tutti hgli SRID che
non usi caschi sempre nel solito posto.
magari dopo avere eliminato gli SRIDridondanti ricordati sempre
di fare VACUUM per compattare fisicamente il DB-file.
le conseguenze di eliminare uno o piu' CRS sono queste due qua:
a) per potere creare una nuova geometria occorre che lo SRID che
dichiari sia presente in "spatial_ref_sys"; se manca ti
dara' un errore fatale.
b) idem per la ST_Transform(): se non trova la definizione dello
SRID anche questa ti da' errore.
insomma, se tu sei ben sicuro che nei tuoi db-file ci andranno
sempre e solo dati piemontesi, non ti serve poi a molto tenerti
nel db tutti gli SRID relativi agli USA o all'oceano pacifico ;-)
.) non consente la rinomina o la cancell
' un limite strutturale intrinseco dell'architettura di
SQLite. e non e' neppure ipotizzabile che venga modificato in un
futuro piu' o meno vicino perche' implicherebbe rivoluzionare
radicamente tutta la struttura fisica di basso livello del DB-file.
detto questo: anche moltissimi altri DBMS non sono minimamente
capaci di modificare i nomi/tipi/vincoli delle colonne una volta
che siano state create.
ma aggirano elegantemente il problema "simulando" a livello
puramente
formale una ALTER TABLE che in effetti compie (sotto al cofano,
in
modo silenzioso ed invisibile) la seguente catena di operazioni:
1) attivare una transazione - BEGIN
2) modificare il nome della tavola di partenza
3) creare una nuova tavola con il vecchio nome ma sopprimendo
(o modificando) le definizioni delle singole colonne cosi'
come richiesto dall'utente.
4) copiare i dati dalla tavola vecchia alla nuova
5) DROP della vecchia tavola
6) consolidare la transazione - COMMIT
Se ci sono relazioni con altre tavole ci possono essere problemi in
questo workaround ?
certamente si: e pure se hai gia' definito qualche VIEW potrebbe
saltare perche' i nomi non combaciano piu'.
idem dicasi se hai definito qualche Trigger customizzato.
funziona sicuramente bene nel caso di tavole semplici che non siano
coinvolte in troppe ulteriori ramificazioni; nei casi piu' complessi
non funziona.
ciao Sandro
_______________________________________________
Gfoss@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
