[Gfoss] problema campo numerico dopo query spatialite

[a.furieri a lqt.it]

On Wed, 11 Mar 2015 12:29:03 +0100, Matteo Ghetta wrote:
> ho aperto un ticket in proposito
>
> http://hub.qgis.org/issues/12356 [2]
>
> però mi è stato suggerito che il problema potrebbe essere dovuto a
> una 'limitazione' di SQlite, ovvero ai datatype
>
> http://www.sqlite.org/datatype3.html [3]
>
> a questo punto, visto che il problema (a mio avviso) non è di poco
> conto, c'è un modo di: fare la query e importare i campi NUMERIC ma
> trasformandoli in REAL?
>

Ciao Matteo,

giusto per aiutarri a capire meglio:

- SQLite ha un'architettura innovativa, che non necessariemente
   ricalca quella p.es. di PostgeSQL (anzi, di fatto siamo decisamente
   agli antipodi).

- SQLite (volutamente, per una precisa scelta di progetto) non
   supporta i data-types a livello di colonna, ma solo a livello di
   singola cella: in questo assomiglia molto piu' ad uno spreadsheet
   che ad un DBMS convenzionale.
   e conseguentemente tutte le dichiarazioni di tipo che appaiono p.es.
   in una CREATE TABLE hanno mero valore "estetico/decorativo", ma
   sono prive di effetti pratici.

giusto per fare un esempio spicciolo; questa e' un'operazione
perfettamente legittima in SQLite:

CREATE TABLE test1 (
   col1 INTEGER,
   col2 VARCHAR(25),
   col3 PINCOPALLINO(400),
   col4 TRULLALLERO);

SQLite non batte ciglio; per lui PINCOPALLINO e TRULLALERO
sono nomi di data-type assolutamente validi proprio come
INTEGER e VARCHAR, nel senso che ignora come assolutamente
irrilevanti sia gli uni che gli altri.

INSERT INTO test1 VALUES (1, 2, 3, 4);
INSERT INTO test1 VALUES ('uno', 'due', 'tre', 'quattro');

entrambe queste INSERT INTO funzionano perfettamente sotto SQLite,
sempre perche' le dichiarazioni del tipo a livello di colonna
sono completamente irrilevanti e vengono praticamente ignorate.

naturalmente i data-types ci sono, ma li trovi direttamente a
livello di ciascun singolo valore-cella; celle della medesima
colonna possono liberamente adottare data-types diversi in
ciascuna riga.
SQLite supporta solo ed esclusivamente questi cinque tipi:
- SQLITE_INTEGER: interi a 8, 16, 32 o 64 bit (decide dinamicamente
   in base al numero di cifre lo spazio di allocazione ottimale)
- SQLITE_DOUBLE: floating point a doppia precisione (64 bit)
- SQLITE_TEXT: stringhe di testo fino a circa 1 miliardo di caratteri.
- SQLITE_BLOB: stringhe binarie fino a circa 1 miliardo di bytes.
- SQLITE_NULL

come vedi, il datatype NUMERIC non esiste affatto (e personalmente
non ho la piu' pallida idea di cosa possa intendere QGIS)

rileggendo le tue mail precedenti, mi pare di capire che il
problema non ti si presenta se alimenti il DB SQLite tramite
SpatiaLite GUI (e che ti imposta un tipo DOUBLE).
immagino quindi che il problema sia sostanzialmente da
identificarsi al livello degli strumenti che hai usato per
alimentare il DB, e che introducono lo stravagante tipo
NUMERIC ... parrebbe l'ipotesi piu' probabile.

puoi comunque fare una verifica abbastanza semplice:

SELECT typeof(col1), typeof(col2), typeof(col3)
FROM qualchetavola;

typeof() ti ritorna direttamente il datatype utilizzato
fisicamente da SQLite per ciascuna cella; in questo modo
dovresti poter ricostruire molto facilmente cosa e'
relamente accaduto al tuo DBMS, e perche' si comporta
diversamente da quello canonico generato da Spatialite-GUI

ciao Sandro