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 àèìòù
-----------------
Il giorno 13 settembre 2014 13:45, Andrea Peri <aperi2007@gmail.com> 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 àèìòù
-----------------
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 <aperi2007@gmail.com> 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 àèìòù
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 <aperi2007@gmail.com> 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 <aperi2007@gmail.com> 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 àèìòù
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
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, <a.furieri@lqt.it> 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 bytesad ogni buon conto: SQLite e’ estremamente configurabile.
se ti ricompili “a manina” libsqlite3 puoi modificarti tutte queste
impostazioni come meglio preferisci.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