In un pannello DO di lookup in cui l’utente può vedere solo alcuni record ho provato la tecnica di modificare la master query di pannello mettendo
where
(ID IN mioCampoIMDBConListaDiIdSeparatiDaVirgola and mioCampoIMDBConListaDiIdSeparatiDaVirgola != "")
OR
(mioCampoIMDBConListaDiIdSeparatiDaVirgola == "")
è un alternativa a calcolarmi la collection e passarla al pannello.
Ho visto che funziona anche con liste di id lunghissime (tipo con 2000 ID), ma la domanda è: vale la pena usare questa tecnica o è meglio usare pannello.setCollection?
Mi ricordo che questa tecnica mi era stata suggerita anni fa da Giuseppe Lanzi durante una consulenza, però non mi ero mai posto il problema del numero di ID.
Supponiamo che io ho un DB con 10000 record e il mio utente ne vede 9998, posso passare una lista di 9998 id: ci sarà probabilmente un limite oltre il quale la tecnica è inefficace, ma qual è?
Diciamo che il mio scopo è avere la business logic nelle classi, quindi che una classe mi generi una collection o una stringa con una lista di id per me è lo stesso.
Ciao Francesco, se lo proponi ad un qualsiasi DBA inorridisce, te lo dico perchè ci sono già passato
i limiti ci sono e variano da db a db ma il problema più grosso è che il db in questo modo esegue “n” scan per pk quanti sono gli id quindi non è per nulla ottimizzata la query
ciao
Mi sono sempre chiesto anche io come gestire queste casistiche, di solito nel mio caso le uso per record selezionati a video, solitamente non tantissimi, però il caso c’è.
In qualche occasione ho “risolto” inserendo in una tabella di elaborazione i docid dei record da estrarre e quindi messa in join/clausola in, comunque sempre un bel numero di query di insert o scan se lo fa.
Ciao Francesco,
sono nuovo in questa community, pur essendo anni che sviluppo in Inde.
Secondo me conviene sempre risalire ai criteri utilizzati per “selezionare” quegli ID, di fatto converrebbe dare all’utente finale un pannello che permetta di effettuare filtri con QBE e registrare questi filtri sottoforma di criteri SQL da passare come where della query, in un progetto ho utilizzato la funzione getQBEFilter per registrare in una tabella imdb le condizioni impostate e riutilizzarle come criteri di filtro.
Grazie a tutti per le risposte e ciao Carlo, benvenuto! Al momento ho implementato la tecnica che ho descritto. Funziona bene, è testabile, ma di certo non scala bene.
Il problema è che non è possibile fare una “where documentale”, quindi un metodo può restituire una lista di id e quella la posso usare in una where.
Ho già intravisto che quando si arriva alle migliaia di record le performance iniziano a traballare, per il mio tipo di applicazione migliaia di record è già un buon limite superiore, però di certo la soluzione è infelice.
Il problema è che le regole sono vere e proprie business rule complesse, non sempre scrivibili come where condition or QBE, sono casi molto complessi. O si scrivono query illeggibili, o si fanno recordset bizzarri o si passa una lista di ID.
Forse la soluzione sarebbe un modo nativo di inde per gestire la cosa, non so esattamente come. Ciao!
grazie per il messaggio. La tecnica che mostri tu so che esiste ma non l’ho mai usata.
Io faccio
ID in LISTA_DI_ID (in cui il pezzo “ID in” lo gestisce Inde e io gli passo solo la stringa con LISTA_DI_ID)
con la tecnica che tu proponi dovrei anche gestire il pezzo “ID in”.
Ora, IDF ha un bug per cui se cambio a runtime il contenuto di una clausola IN senza ricreare il form, la query non si aggiorna, ho fatto una prova al volo e anche “la tua tecnica” funziona così. Ovvero se cambio il valore dell’iMDB a form aperto la query non è riscatenata automaticamente.
Quindi la tua tecnica pone altre sfide (tipo capire come scrivere bene la condizione, tipo “A.CUSTID IN”, se invece uso la clause IN del VCE quel pezzo me lo scrive lui.
comunque segnalerò che anche la tua tecnica ha quel problema.
In ogni caso scrivere a mano la condizione where dà maggiore controllo, ma se lo scopo è passare una lista di ID, comunque i problemi esposti negli altri commenti restano validi: ovvero il DB non è felice di ricevere un
