problemi con indici spaziali sqlite
Locked
12
12
 
|
Piccole note:
INSERT INTO test (id, geom4326) VALUES (NULL, MakePoint(42.11, 11.41, 4326)); Intendevi scrivere INSERT INTO test (*geom3003*, geom4326) VALUES (NULL, MakePoint(42.15, 11.45, 4326)); ?
conseguenza naturale e inevitabile del fatto che la catena dei trigger è depth-first. Analisi degli effetti non scantata e decisamente utile, grazie Sandro!
giovanni _______________________________________________ [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 iscritti al 22.7.2013 |
|
|
On Fri, 21 Feb 2014 13:09:54 +0100, G. Allegri wrote:
> Piccole note: > >> INSERT INTO test (id, geom4326) VALUES (NULL, MakePoint(42.11, >> 11.41, 4326)); > > Intendevi scrivere > INSERT INTO test (*geom3003*, geom4326) VALUES (NULL, > MakePoint(42.15, > 11.45, 4326)); > > ? > no, proprio come ho scritto: il NULL inizializza la Primary Key autoincrement, geom3003 non viene neppure citata di striscio e quindi assumera' il default value (cioe' NULL) > conseguenza naturale e inevitabile del fatto che la catena dei > trigger > è depth-first. > e questo conferma definitivamante che ha piu' o meno lo stesso livello di sicurezza intrinseca come maneggiare della nitroglicerina a ruota libera ;-) 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 iscritti al 22.7.2013 |
Re: problemi con indici spaziali sqlite
|
|
OK, grazie mille dell'analisi approfondita che adesso andrò a leggermi e a provare con attenzione.
A questo punto però vi chiedo una cosa più generica. Come procede lo sviluppo di spatialite ? Quanto sta investendo la comunità su SL ?
Io ho iniziato a lavorarci da poco e mi è sembrato uno strumento assolutamente fondamentale e dalle ampie potenzialità. Anche con le mie scarse capacità grazie a SL sono riuscito a risolvere parecchi dei problemi.
Tempo addietro si parlava di SL come dello shapefile del futuro, ed in effetti le potenzialità ci sono, però a leggere questo treadh mi viene un po' di depressione. Insomma, utilizzare SL sembra molto più complicato di quello che pare a prima vista e ci sono risvolti non da poco da tener conto. In diversi ambiti lavorativi non posso permettermi di maneggiare nitroglicerina o scalare ad ampia quota, devo affidarmi alla sicurezza e all'affidabilità.
Se esiste un forte interesse da parte della comunità tutto questo è sorpassabile e per me SL rimane uno strumento su cui investire. In lista però leggo poco o niente sul futuro di SL, da qui la mia cursiosità di saperne di più da parte di chi sta dietro allo sviluppo.
grazie >L< Il giorno 21 febbraio 2014 13:16, <[hidden email]> ha scritto:
_______________________________________________ [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 iscritti al 22.7.2013 |
|
|
Lascio la risposta a Sandro, ma permettimi di dire che il punto è far sì che gli strumenti, delegati a gestire un db Spatialite, siano fatti in modo da assicurare la corretta gestione di tutti gli aspetti che vanno maneggiati con cura. Spatialite (Sqlite) sono strumenti raffinatissimi, con uno sviluppo gestito con tutti i crismi per garantire sicurezza e affidabilità. Ciò non toglie che possa essere usato (inconsapevolmente) male. giovanni Il 21/feb/2014 14:21 "Luca Lanteri" <[hidden email]> ha scritto:
_______________________________________________ [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 iscritti al 22.7.2013 |
Re: problemi con indici spaziali sqlite
|
|
Non dimentichiamo che è possibile fare dei bei casini anche su oracle e su postgres. Ad esempio, su oracle non è cosi' infrequente che un applicativo di caricamento disabiliti tutti i constraints per riuscire a caricare i dati. Il punto è che poi deve ricordarsi (l'applicativo) di riabilitarli. Il che non è detto, ma non è neanche detto che una volta riattivati, i dati che si sono insertii ci restino. :) Non è qui che si gioca la differenza tra un dbms e uno spatialite. La vera differenza è nel fatto che un db spatialite è tutto racchiuso su un file che è del codice binario. Se uno prende un editor esadecimale e ci scrive a casaccio dentro , lo rovina sicuramente, non ci sono trigger o foreign-key che tengano. Al posto dell'editor esadecimale, ci puo' stare anche un codice eseguibile che scriva roba in modo piu' o meno errato. Il succo è lo stesso. Anche su oracle se avessi accesso al filesystem dove stanno i datafile di oracle e ci vado a scrivere con un editor esadecimale valori a casaccio ottengo il medesimo risultato. Quindi la grande differenza che ha spatialite rispetto a un dbms tradizionale (come oracle e postgres) è che il file dove ci sta il dato non è fisicamente raggiungibile su postgres/oracle perche' relegato su una macchina diversa con cui si colloquia remotamente con comandi insert/delete/update etc... Mentre lo sqlite è fisicamente raggiungibile. E' qui la differenza vera. E' lo svantaggio di spatialite/sqlite, ma è anche il suo vantaggio. Perche' consente di funzionare senza doversi connettere in remoto con un dbms. A. On 21/02/2014 14:29, G. Allegri wrote:
_______________________________________________ [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 iscritti al 22.7.2013 |
Re: problemi con indici spaziali sqlite
|
|
In reply to this post by giohappy
Giovanni, mi sembra un punto di vista più che corretto, quindi allargo la mia domanda anche agli strumenti annessi.
Ovviamente non pretendo che tutto sia per forza facile, figurati ! Con Postgres ho smoccolato non poco, ma alla fine ho imparato ad utilizzare uno strumento che secondo me nel suo campo non ha pari. Con SL ho la stessa impressione: flessibilità, leggerezza, potenzialità ottime e soprattutto portatile ! E' per questo che mi piacerebbe capire in che direzione sta andando SL e tutto quanto gli gravita attorno. Mi pare strano che non sia uno degli argomenti più gettonati in lista e che lo sviluppo degli strumenti che gli gravitano in torno non stia viaggiando a mille !
>L< Il giorno 21 febbraio 2014 14:29, G. Allegri <[hidden email]> ha scritto:
_______________________________________________ [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 iscritti al 22.7.2013 |
|
|
Non prendere per riferimento solo questa lista. Se guardi la mailing list di Spatialite vedrai che di attività ce n'è eccome! Spatialite è impiegato in molti contesti, al di là del GIS classico...
giovanni
_______________________________________________ [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 iscritti al 22.7.2013 |
Re: problemi con indici spaziali sqlite
|
|
ok, vado a dargli un'occhiata subito, grazie. >L< Il giorno 21 febbraio 2014 15:59, G. Allegri <[hidden email]> ha scritto:
_______________________________________________ [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 iscritti al 22.7.2013 |
|
|
In reply to this post by Luca Lanteri-3
On Fri, 21 Feb 2014 14:21:34 +0100, Luca Lanteri wrote:
> Io ho iniziato a lavorarci da poco e mi è sembrato uno strumento > assolutamente fondamentale e dalle ampie potenzialità. Anche con le > mie scarse capacità grazie a SL sono riuscito a risolvere parecchi > dei problemi. > Tempo addietro si parlava di SL come dello shapefile del futuro, ed > in > effetti le potenzialità ci sono, però a leggere questo treadh mi > viene un po' di depressione. Insomma, utilizzare SL sembra molto > più complicato di quello che pare a prima vista e ci sono risvolti > non da poco da tener conto. In diversi ambiti lavorativi non posso > permettermi di maneggiare nitroglicerina o scalare ad ampia quota, > devo affidarmi alla sicurezza e all'affidabilità. > Luca, ogni strumento tecnologico ha pregi e difetti; anzi, per la precisione, quelli che in un determinato contesto sono pregi possono facilmente diventare difetti in un contesto diverso e viceversa. SQLite (e quindi di riflesso SpatiaLite) ha diversi punti di forza assolutamente degni di nota e che lo rendono praticamente unico: - e' cosi' tanto leggero e strutturalmente semplice che gira bene anche su Android e su altre piattaforme che offrono risorse HW risicatissime (smartphone, embedded devices etc) - ma e' anche decisamente robusto ed affidabile, e spesso (non sempre) scala assai bene anche nei piu' classici contesti workstation o server - dato che un DB e' semplicemente un file monolitico con architettura universale, permette di scambiare molto facilmente grandi masse di dati altamente strutturati tra piattaforme eterogenee tramite una banale operazione di copia. - supporta quasi interamente la sintassi ISO SQL standard - non ha praticamente bisogno di processi di configurazione e manutenzione da parte dell'utente finale naturalmente ogni rosa si porta sempre dietro qualche spina: - non e' client server: e soffre di terribili problemi per gli accessi concorrenti in scrittura, che risultano di fatto impossibili. - alcuni dettagli dell'implementazionei SQL sono significativamente differenti da quanto viene normalmente implementato nei piu' comuni DBMS client-server (giusto per dire, SQLite non ha i data-types) - a volte alcuni meccanismi sono decisamente "ruvidi"; funzionano, e funzionano in modo efficiente, ma richiedono certamente un qualche sforzo extra da parte degli sviluppatori per operare al meglio. e' un po' come il cambio della vecchia 500 (per chi ancora se lo ricorda); certamente funzionava, ma se non eri bravo a fare la "doppietta" ti ci potevi spaccare un polso (oltre a rimanere piantanto in folle nel momento meno opportuno) ;-) - last but not least: dato che e' semplicemente un'unica libreria che funge simultaneamente tanto da server quanto da client, e' un componente sw altissimamente configurabile. credo che le opzioni di build (comprese quello "occulte" che si scoprono solo spulciando il codice) siano svariate centinaia. ed e' fortemente configurabile tanto in fase di build quanto in fase di runtime. il che e' di per se sicuramente un'ottima caratteristica fino a quando lo si usa direttamente dentro ad una singola app di cui un unico gruppo di sviluppo/distribuzione riesce a controllare tutti i minimi dettagli. e' assai meno ottimale quando si va a costruire un framework complesso (magari multi-piattaforma e multi-linguaggio) in cui esiste una plurarita' di componenti indipendenti che pero' devono operare a strettissimo contatto. il rischio di costruire "un'orchestra stonata" diventa quindi molto alto, come purtroppo sanno bene gli utenti QGIS che hanno avuto in passato la spiecavola esperienza di scoprire che il data-provider da un lato, ed i plug-in Python dall'altro stavano usando versioni spaiate delle librerie che causavano conflitti insanabili. insomma, esistono certamente alcuni scenari in cui scegliere oculatamente e' molto facile: - devi lavorare su micro-devices ? non hai alternative: sqlite e' l'unico candidato serio. - devi gestire cento utenti che lavorano in concorrenza parallela ? scordati immediatamente sqlite, sara' un fallimento totale. tutto quel che cade nel mezzo e' "area grigia", ed evidentemente la scelta finira' per dipendere da un sacco di fattori variabili che non e' possibile ridurre a qualche facile formuletta stereotipata e preconfezionata. in base ai ritorni d'uso di cui sono direttamente a conoscenza (piu' che altro grazie alla ML di progetto di SpatiaLite), lo spettro degli utenti soddisfatti spazia da organizzazione di livello governativo che hanno spento con piena soddisfazione svariate istanze di un blasonato (ed assai costoso) Spatial DBMS proprietario per passare a splite, fino ad arrivare ad una pletora di giovani sviluppatori tutti felici e contenti perche' splite gli consente di sviluppare facilmente apps con un buon livello di supporto Spatial su trespolini ultra-light Android o .NET nel mezzo ci trovi un pattuglione di ricercatori universitari e/o professionisti che devono processarsi un sacco di dati geolocalizzati ma che hanno a ben poco (o nulla) a che fare con i classici paradigmi GIS, e che preferiscono lavorare quasi esclusivamente tutto a colpi di SQL (magari appoggiandosi anche su Python o altri linguaggi di scripting): solo alla fine del processo esportano qualche SHP ed utilizzano qualche GIS "classico" per le operazioni di rendering e stampa degli elaborati. sporadicamente si e' anche affacciato qualche sviluppatore di video games (lo Spatial Processing serve ovviamente anche a loro). il caso d'uso piu' bizzaro di cui sono a conoscenza e' quello di un artista berlinese che usa spatialite per produrre i suoi quadri di arte moderna rielaborando via SQL alcune tracce GPS :-) ma se ti affascinano le stravaganze ti consiglio di seguire la ML di SQLite, dove scoprirai che esiste un sotto-gruppo molto attivo interamente dedicato allo sviluppo di un "solutore universale di Sudoku" tutto integralmente basato su SQL :-D infine, giusto per concludere questa pur sommaria carrellata, abbiamo una discreta pattuglia di utenti QGIS che finisce per approdare dalle parti della ML spatialite in cerca di assistenza e di conforto quando incontrano qualche osso particolamente duro. generalizzare e' sempre sbagliato, ma qualche pattern interessante direi che comunque emerge: - molti dei problemi riportati nascono da un uso "estremo" delle Spatial VIEWs - seguiti a ruota da analoghi problemi causati da un uso altrettanto "spericolato" dei Triggers (n.b.: il che e' di per se notevole ed assai indicativo, visto che quasi mai gli utenti di tipo piu' ortodosso SQL-oriented sollevano problemi relativi a Views e Triggers ... evidentemetne c'e' qualche distorsione sistematica all'opera) - non di rado si riscontrano problemi causati da un uso poco oculato di versioni mescolate piu' o meno a caso. - spesso mi pare di poter notare una scarsa consapevolezza riguardo alle mille idiosincrasie specifiche di SQLite e di SpatiaLite ... insomma, l'impressione e' che non di rado si navighi un po' "ad orecchio" e "per sentito dire", piu' che per approfondita conoscenza degli strumenti specifici sqlite/splite. immagino quindi che gli utenti QGIS spesso finiscano per annaspare su problemi riconducibili a SQL/sqlite/spatialite piu' che altro perche' stanno tentando di avventurarsi alla ricerca di non facili equilibri alchemici che riescano in qualche modo ad aggirare il classico data-model "flat table" tipico dei layer GIS modellati a misura di shapefile. ... ma la strada dei workarounds e' sempre notoriamente cosparsa di spine pungenti ;-) sinceramente non credo che il problema sarebbe poi molto diverso se si tentesse di utilizzare PostGIS oppure qualche altro DBMS; immagino che cambierebbe ben poco. quel che invece so per certo e' che questo e' un campo di utilizzo in cui sqlite/spatialite puo' entrare molto facilmente in sofferenza, perche' i numerosi vincoli e tutte le specificita'/idiosincrasie intrinseche in un'implementazione "ultra-light", a volte "scorbutica" e sostanzialmente "eretica" verrano stiracchiati fino all'estremo. ed assai verosimilmente, specie in presenza di un know-how specifico non del tutto adeguato, si finira' per cadere in qualche trappolone. "semplice" e "leggero" non sempre significa anche "facile", specie quando si cerca di spingersi agli estremi oltre ai limiti standard dell'implementazione base .... magari funziona anche, ma quasi di sicuro tocchera' sudare un bel po' per avere successo ;-) 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 iscritti al 22.7.2013 |
Re: problemi con indici spaziali sqlite
|
|
Hai assolutamente ragione, il parallelo con la ruvidezza del cambio della 500 descrive bene la sensazione che ho avuto iniziando a lavorare su SL. Di contro però SL mi sembra il migliore GeoDB non client-server in circolazione e questo non è poco. Probabilmente mi sono spiegato male: non volevo fare un confronto con altri DB server-client come PG e che appartengono a tutt'altra categoria. La ultima mia domanda voleva essere uno stimolo per intavolare quattro chiacchere in lista sul futuro di questo strumento e per conoscere meglio quali sono le prospettive future. Ho seguito con interesse il tuo intervento del GFOSS di Torino nel 2012 e mi chiedevo, a distanza di 2 anni, quanto si fosse andati avanti e soprattutto quali fossero le prospettive di SL. Ho ancora molto da leggere e da imparare, ma per rendere più amichevole uno strumento a me piace conoscere oltre che gli aspetti puramente tecnici, anche, come diceva Quelo: "dove stiamo andanto su questa tera".
;-) a presto 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 iscritti al 22.7.2013 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |