[Gfoss] problemi con indici spaziali sqlite

Ven 21 Feb 2014 09:23:49 CET

Ho dato una lettura al documento che indicavi.

Riassumendo:
prima della sqlite 3.6.18 i trigger ricorsivi non erano supporti e quindi
vanno eviate versioni di sqlite cosi' vecchie.

Nelle versioni successive, pero' i trigger ricorsivi erano disabilitati
by-default, ppunto come dicevi te.
Quindi occorre sempre inserire una clausola

PRAGMA recurvive_triggers=1

Usando gli applicativi di spatialite:
CLI e Spatialite-GUI.
Questa clausola
recursive_triggers va settata comunque o è implicita ?

Detto questo.

se un disgraziato lavora su QGIS, editando un dataset tramite la finestra
degli attributi, oppure trmaite le form customized che ora qgis consente,
tale clausola "recursive_triggers=1" probabilmente è a 0 , ma come puo'
fare per garantirsi di settarla a 1 ?

Qui mi sorge un dubbio serio...
E forse comincio a capire perche' a suo tempo ebbi dei problemi...

A

Il giorno 20 febbraio 2014 22:31, <a.furieri a lqt.it> ha scritto:

> On Thu, 20 Feb 2014 21:44:33 +0100, Luca Lanteri wrote:
>
>> Io creo la colonna della geometria con RecoverGeometryColumn(), poi
>> popolo semplicemente i dati mediante un update della colonna
>> geometrica, prendendo la geometria da un'atra tabella invece che
>> dall'interfaccia di qgis. I trigger che popolano gli indici dovrebbero
>> essere scatenati tanto dal mio update quanto da un inserimento diretto
>> in QGIS, no ?
>>
>>
> ok, almeno in teoria torna perfettamente:
> - RecoverGeometryColumn() dovrebbe installare tutti i triggers
> - dopo di che ogni volta che fai un'INSERT/UPDATE/DELETE l'R*Tree
>   verra' immediatamente aggiornato perche' ci pensano comunque i
>   triggers in modo automatico.
>
> natualmente, tra la teoria e la pratica c'e' sempre spazio a sufficienza
> perche' ci si infili in mezzo lo zoccolo bifido di Messer Satanasso :-)
>
>
>  Spero che cosi sia, visto che sto utilizzando Sqlite proprio per poter
>> utilizzare le funzionalità dei trigger.
>>
>>
> questo fa nascere un dubbio ulteriore: i Triggers di SQLite sono basati
> su una buona implementazione, ma ci sono alcuni caveats da tener di conto:
> - alcune versioni molto vecchie (< 3.7.x) non dovrebbero essere in grado
>   di supportare Triggers ricursivi.
>   cioe', se un triggers fa partire un secondo trigger che ne scatena un
>   terzo etc, con le vecchie versioni dovrebbe partire solo il primo,
>   perche' poi la catena si spezza
> - ma anche con le versioni recenti, c'e' comunque un limite nei livelli
>   di nidificazione supportati dai triggers.
>   e comunque occorre invocare esplicitamente una PRAGMA per abilitare la
>   ricursivita' per i Triggers (by default e' comunque disabled).
>   vedi: http://www.sqlite.org/pragma.html#pragma_recursive_triggers
>
>
>
>  A questo punto, qual'è lo strumento migliore per creare un DB
>> Spatialite DOC, come lo chiamava Andrea ?
>>
>>
> naturalmente il mio non e' un parere spassionato: ma non ho comunque
> il minimo dubbio. spatialite CLI oppure SpatiaLite GUI
>
> cioe' i due strumenti piu' strettamente integrati con il DBMS, direttamente
> gestiti dal medesimo gruppo di sviluppatori che segue il DBMS, e che sono
> quindi sempre certamente allineati con le specifiche tecniche del DBMS via
> via che vanno evolvendosi di versione in versione.
> e che piu' facilmente tendono a recepire una vasta casistica di casi d'uso
> che spaziono dalle micro-app per Android/smartphones fino alle piu'
> complesse applicazioni ultra-professionali in contesti enterprise.
>
>
>
>
>  Io li ho sempre creati da QGIS, che tra l'altro nella versione 2.0 mi
>> pare ci metta un tempo eterno (non vorrei che il problema fosse
>> proprio li). Con la 2.1 i tempi di creazione sono decisamente più
>> sensati.
>>
>>
> in occasione del rilascio di splite v.4.0 e' stato introdotto un
> modestissimo cambiamento in una funzione SQL legata all'inizializzazione
> di un nuovo DB.
> modifica peraltro messa in forte rilievo nelle note di rilascio, ed
> abbondamente discussa piu' e piu' volte nella ML di spatialite.
> qgis 2.0 non ha supportato tempestivamente la modifica, e quindi e'
> soggetto ad una discreta lentezza in fase di creazione di un nuovo DB
> (anche se comunque alla fine i risultati del processo sono perfettamente
> corretti); viceversa poi qgis 2.1 e' stato correttamente aggiornato,
> ed ora alla fine tutto e' tornato a funzionare in modo ottimale.
>
>
>
>  Esiste un modo per verificare se un DB Spatialite è corretto ed ha
>> tutti i trigger e gli indici a posto?
>>
>>
> in linea di massima non e' possibile, perche' la casistica "degli
> interventi cinesi" (come li chiama Andrea) e' potenzialmente illimitata.
> in caso di dubbio una chiamata (tutta di seguito) a questa coppia di
> funzioni dovebbe rimettere tutti i Triggers per ciascuna colonna geometrica
> correttamente a posto:
> - DiscardGeometryColumn()
> - RecoverGeometryColumn()
>
>
>  Se ci fossero problemi esiste il modo di farne un repair ?
>>
>>
>
> ci sono due funzioni SQL fatte apposta per verificare/ricostruire
> gli Spatial Index (quantomeno, nei casi d'uso piu' comuni e ragionevoli):
> - CheckSpatialIndex()
> - RepairSpatialIndex()
>
> qua ci trovi maggiori informazioni:
> http://www.gaia-gis.it/gaia-sins/SpatialIndex-Update.pdf
>
>
> ciao Sandro
> _______________________________________________
> Gfoss a 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 iscritti al 22.7.2013
>

-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20140221/1951bbe7/attachment.html>