Gfoss -- Geographic Free and Open Source Software - Italian mailing list

Spatialite e limite di parametri in una singola query

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Andrea Peri

Spatialite e limite di parametri in una singola query

Io non userei una serie smisurata di AND,
anche perche' metti a dura prova l'ottimizzatore della query.

Proverei a usare invece il costrutto IN

where
campo1 IN ('valore1','valore2','valore3',.....)

Anche su postgres.

prova e facci sapere se questo ammette piu valori di 999

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[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+40 iscritti al 5.6.2014

mando

Re: Spatialite e limite di parametri in una singola query

Il giorno 13 settembre 2014 13:45, Andrea Peri <[hidden email]> ha scritto:

Io non userei una serie smisurata di AND,
anche perche' metti a dura prova l'ottimizzatore della query.

Proverei a usare invece il costrutto IN

where
campo1 IN ('valore1','valore2','valore3',.....)

No, non funzia, lo vede sempre come un eccesso di patametri

Anche su postgres.

Postgres digerisce anche i sassi. Non ha problemi

prova e facci sapere se questo ammette piu valori di 999

Aggirerò il problema così:

memorizzo in un dizionario le coppie campi/valori che creano l'istanza di database in un dato momento. Così non dovrò cercare gli ID tramite un IN.

Nel caso avessi un'istanza di database che corrisponde a tutti i record faro solo una query id > 0.

Per eliminare per esempio più di 1000 record non farò altri che segmentare i delete in pacchetti da 500.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

_______________________________________________
[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+40 iscritti al 5.6.2014

Andrea Peri

Re: Spatialite e limite di parametri in una singola query

>Aggirerò il problema così:

>memorizzo in un dizionario le coppie campi/valori che creano l'istanza di database in un dato momento. Così non dovrò cercare gli ID tramite un IN.

Non ho chiaro quello che devi fare, ma indubbiamente vi e' un limite nella lunghezza della espressione.

Pero' se cosi' e' , e se come ho capito te memorizzi gli ID in una tabella (il tuo dizionario),
li puoi invocare cosi':

where
campo1 IN (select valore from dizionario)
;

Se il problema e' la lunghezza della stringa SQL che non puo superare una certa lunghezza,
questa ultima sintassi dovrebbe funzionare.

E forse potresti anche usare

where
campo1 EXISTS (select valore from dizionario)

A.

Il 13/09/2014 19:26, Luca Mandolesi ha scritto:

Il giorno 13 settembre 2014 13:45, Andrea Peri <[hidden email]> ha scritto:

Io non userei una serie smisurata di AND,
anche perche' metti a dura prova l'ottimizzatore della query.

Proverei a usare invece il costrutto IN

where
campo1 IN ('valore1','valore2','valore3',.....)

No, non funzia, lo vede sempre come un eccesso di patametri

Anche su postgres.

Postgres digerisce anche i sassi. Non ha problemi

prova e facci sapere se questo ammette piu valori di 999

Aggirerò il problema così:

memorizzo in un dizionario le coppie campi/valori che creano l'istanza di database in un dato momento. Così non dovrò cercare gli ID tramite un IN.

Nel caso avessi un'istanza di database che corrisponde a tutti i record faro solo una query id > 0.

Per eliminare per esempio più di 1000 record non farò altri che segmentare i delete in pacchetti da 500.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

mando

Re: Spatialite e limite di parametri in una singola query

Ho delle semplici interfacce grafiche in QT che visualizzano i dati, permettono di navigare e fare delle ricerche. Quindi quando voglio fare una ricerca, non faccio altro che svuotare le caselle di testo presenti nella gui, uno scrive dentro il volore e lo script li associa al campo della tabella.

Non uso il metodo interno delle QT ma passo per SQLalchemy che mi permette di dialogare con postgres e sqlite senza cambiare nulla. Unica problema è proprio lato SQlite che mi pone un limite di 999 parametri ricercabili contemporaneamente.

Il giorno 13 settembre 2014 20:25, aperi2007 <[hidden email]> ha scritto:

>Aggirerò il problema così:

>memorizzo in un dizionario le coppie campi/valori che creano l'istanza di database in un dato momento. Così non dovrò cercare gli ID tramite un IN.

Non ho chiaro quello che devi fare, ma indubbiamente vi e' un limite nella lunghezza della espressione.

Pero' se cosi' e' , e se come ho capito te memorizzi gli ID in una tabella (il tuo dizionario),
li puoi invocare cosi':

where
campo1 IN (select valore from dizionario)
;

Se il problema e' la lunghezza della stringa SQL che non puo superare una certa lunghezza,
questa ultima sintassi dovrebbe funzionare.

E forse potresti anche usare

where
campo1 EXISTS (select valore from dizionario)

A.

Il 13/09/2014 19:26, Luca Mandolesi ha scritto:

Il giorno 13 settembre 2014 13:45, Andrea Peri <[hidden email]> ha scritto:

Io non userei una serie smisurata di AND,
anche perche' metti a dura prova l'ottimizzatore della query.

Proverei a usare invece il costrutto IN

where
campo1 IN ('valore1','valore2','valore3',.....)

No, non funzia, lo vede sempre come un eccesso di patametri

Anche su postgres.

Postgres digerisce anche i sassi. Non ha problemi

prova e facci sapere se questo ammette piu valori di 999

Aggirerò il problema così:

memorizzo in un dizionario le coppie campi/valori che creano l'istanza di database in un dato momento. Così non dovrò cercare gli ID tramite un IN.

Nel caso avessi un'istanza di database che corrisponde a tutti i record faro solo una query id > 0.

Per eliminare per esempio più di 1000 record non farò altri che segmentare i delete in pacchetti da 500.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

a.furieri

Re: Spatialite e limite di parametri in una singola query

On Sun, 14 Sep 2014 11:03:11 +0200, Luca Mandolesi wrote:
> Unica problema è proprio lato SQlite che mi pone un limite di 999
> parametri ricercabili contemporaneamente.
>

dalla doc ufficiale di SQLite [1]

SQLite allocates space to hold all host parameters between 1 and the
largest host parameter number used. Hence, an SQL statement that
contains
a host parameter like ?1000000000 would require gigabytes of storage.
This could easily overwhelm the resources of the host machine.
To prevent excessive memory allocations, the maximum value of a host
parameter number is SQLITE_MAX_VARIABLE_NUMBER, which defaults to 999.

[1] http://www.sqlite.org/limits.html

> Non uso il metodo interno delle QT ma passo per SQLalchemy che mi
> permette di dialogare con postgres e sqlite senza cambiare nulla.
>

evidentemente SQLalchemy macina il tutto internamente in modo
tale da utilizzare i parametri posizionali, e quindi va a sbattere
sul limite duro dei 999 max.

se tu avessi usato direttamente le API standard di SQLite senza
ulteriori intermediari suppongo che il problema non si presenterebbe
affatto, visto che nei tuoi snippets SQL non riesco a vedere
traccia di parametri posizionali.
ed in questo caso il limite max. di SQLite e' che uno statement
SELECT non puo' essere piu' lungo di 1 milione di bytes

ad ogni buon conto: SQLite e' estremamente configurabile.
se ti ricompili "a manina" libsqlite3 puoi modificarti tutte queste
impostazioni come meglio preferisci.

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+40 iscritti al 5.6.2014

mando

Re: Spatialite e limite di parametri in una singola query

Ciao Alessandro e grazie della risposta.

Sono passato da SQLalchemy dato che mi permette di scrivere le funzioni senza preoccuparmi del DB che gira sotto. Questo perchè posso avere un postgres centrale e tanti piccoli PC in missione che usano spatialite che è un file secco. Ricompilare a manina per me è un eufemismo. Non saprei nemmeno da dove partire.

Invece con un semplice campo di appoggi ad ogni tabella che assume 1 o 0 per l'istanza di database di quel momento posso fare la query di tutti i record che voglio in un istante!

Il problema è sorto passando da postgres a spatialite e non avevo mai letto la doc ufficiale di sqlite..ma poco male...aggiro!

Grazie mille

Luca

Il giorno 22 settembre 2014 19:07, <[hidden email]> ha scritto:

On Sun, 14 Sep 2014 11:03:11 +0200, Luca Mandolesi wrote:

Unica problema è proprio lato SQlite che mi pone un limite di 999
parametri ricercabili contemporaneamente.

dalla doc ufficiale di SQLite [1]

SQLite allocates space to hold all host parameters between 1 and the
largest host parameter number used. Hence, an SQL statement that contains
a host parameter like ?1000000000 would require gigabytes of storage.
This could easily overwhelm the resources of the host machine.
To prevent excessive memory allocations, the maximum value of a host
parameter number is SQLITE_MAX_VARIABLE_NUMBER, which defaults to 999.

[1] http://www.sqlite.org/limits.html

Non uso il metodo interno delle QT ma passo per SQLalchemy che mi
permette di dialogare con postgres e sqlite senza cambiare nulla.

evidentemente SQLalchemy macina il tutto internamente in modo
tale da utilizzare i parametri posizionali, e quindi va a sbattere
sul limite duro dei 999 max.

se tu avessi usato direttamente le API standard di SQLite senza
ulteriori intermediari suppongo che il problema non si presenterebbe
affatto, visto che nei tuoi snippets SQL non riesco a vedere
traccia di parametri posizionali.
ed in questo caso il limite max. di SQLite e' che uno statement
SELECT non puo' essere piu' lungo di 1 milione di bytes

ad ogni buon conto: SQLite e' estremamente configurabile.
se ti ricompili "a manina" libsqlite3 puoi modificarti tutte queste
impostazioni come meglio preferisci.

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+40 iscritti al 5.6.2014