DO: Lookup - query di decodifica (2)

[t.simoncini]

Torno sull'argomento
viewtopic.php?f=2&t=11066

Trovo questo comportamento un po' limitante in certi casi. Capisco che sia difficile se non impossibile tradurre in SQL qualsiasi condizione di where impostata nel VCE quando la master table è una classe DO. Chiaramente il documento DO potrebbe avere una MQ piuttosto complessa, in cui è difficile andare a tradurre e inserire una where, però ci sono casi piuttosto semplici (che vanno al di là dello statement proprietà = valore) in cui si potrebbe benissimo risolvere la SQL senza dover ricorrere all'evento OnGetSmartLookup, con tutto quello che ne consegue.

Mi viene in mente il caso semplice, in cui la classe DO sia legata ad una tabella master, in cui le sue proprietà sono collegate ai rispettivi campi DB. In questo caso, se non uso nel where delle proprietà calcolate o non collegate a campi della master table della classe, non dovrebbero mai esserci problemi a tradurre anche condizioni complesse.

Nel nostro gestionale, ma sicuramente non siamo i soli, molti lookup sono condizionati in base alle informazioni precedentemente inserite dall'utente.
Nessun'altro trova scomodo il comportamento attuale?

[a.maioli]

Capisco la richiesta.
Gli eventi BeforeLookup e AfterLookup e OnGetSmartLookup servono proprio per personalizzare il comportamento del lookup in questi casi.
In altri casi di questo genere, quando ad esempio si devono usare tabelle in join puoi sempre utilizzare un lookup basato su tabelle invece che su documenti.

[t.simoncini]

Gli eventi BeforeLookup e AfterLookup e OnGetSmartLookup servono proprio per personalizzare il comportamento del lookup in questi casi.

Infatti il "problema" è che per qualsiasi cosa leggermente più complicata, si deve ricorrere agli eventi, aumentando la complessità del codice e la difficoltà di manutenzione.

In altri casi di questo genere, quando ad esempio si devono usare tabelle in join puoi sempre utilizzare un lookup basato su tabelle invece che su documenti.

Si e no... nel senso che il grande vantaggio della DO, è poter usare della MQ di caricamento con query scritte in un punto solo. Se sono costretto a riscrivere tutte le where che ho messo sulla MQ della classe, anche sulle query di lookup, il gioco non vale più la candela. Senza contare che sulle nostre classi DO vengono sempre aggiunte condizioni generali per controllo accesso ai dati, filtri generali, ecc.. che potrei difficilmente riportare in tutte le lookup dell'applicazione.

Sulle join ti do ragione. Non era un caso che mi aspettavo di vedere risolto.

Ti faccio un piccolo esempio con tre condizioni che secondo me potrebbero benissimo essere tradotte.

1.png (42.33 KiB) Viewed 2136 times

[a.maioli]

Abbiamo creato l'attività NPQ02071 per tenere conto di questa conversazione. Quando verrà valutata, potrai seguirne l'andamento con Instant Developer Roadmap.