Ero incerto se scrivere qui o nel forum, visto che lo scopo è stimolare una riflessione e una discussione, ho deciso che questo è il posto giusto.
Ho appena indagato, e risolto, un problema legato a delle collection non legate a foreing key su database. In sostanza, il problema era dovuto ad una loadCollectionFromDb eseguita su una collection non legata ad una fk, che tentava di caricare l’intero contenuto della tabella (non avendo una clausola where di filtro legata alla fk), per poi eseguire un ciclo su di essa. La procedura in questione è generalizzata ed usata in un evento globale del document helper.
Ho aggiunto quindi un test, se la collection è transient non deve fare nulla. Poi ho spulciato le atre procedure, alla ricerca di qualche altro possibile intoppo di questo tipo.
Mi pongo però un quesito: è corretto che il framework mi permetta di eseguire una loadCollectionFromDb per una collection non legata a fk? Non dovrebbe essere considerato un errore a priori?
1 Mi Piace
@r.bianco direi che un quesito del genere è corretto che stia qui.
Tu dici ho legato una collection ad un documento e non ho un fk e nemmeno una master query che ne indica l’eventuale filtro.
Perché Instant Developer Foundation non mi avvisa anche solo con un warning di compilazione da confermare?
Avere una collection in queste condizioni mi pare un errore di progettazione della struttura ma effettivamente il frame work potrebbe avvisarti.
Cosa ne pensano gli altri sviluppatori Foundation?
2 Mi Piace
Per questa domanda ti rispondo sul forum (l’oggetto da usare è IDCollectionDefinition)
1 Mi Piace
Questa collection, transient, viene popolata da una procedura runtime.
Era capitato anche a me di usare la loadCollectionFromDb (per errore, in realtà volevo usare la loadCollectionFromExample) per caricare una collection non collegata da fk (oggetto generato da procedura come nel caso di r.bianco) e ci ho messo un po’ a capire perchè non mi caricava i dati come mi aspettavo.
Se il corretto funzionamento del metodo ha senso solo per collection legate ad una fk allora appoggio la posizione di r.bianco.
In realtà Paolo non è un errore di progettazione perchè ormai io uso visual code anche per gestire algoritmi un po’ più complessi che non sono strettamente legati alla struttura delle tabelle come da design ma ad una struttura denormalizzata secondo il bisogno. Es. generiamo una struttura di classi documentali che tramite master query “assemblano” dati da tabelle diverse e poi generiamo un json di esportazione per sistemi esterni all’applicazione (spero di essermi spiegato altrimenti chiarisco meglio il caso).
2 Mi Piace
Direi che possiamo inserire una proposta di modifica che avvisi della situazione con un warning di quelli che vanno poi confermati dall’utente per compilare. In questo modo ci si accorge della situazione.
@r.bianco inserisci tu la proposta su CRM Pro Gamma ?
Poi noi andiamo tutti a votarla e magari la troviamo nella 22.0 di Maggio.
Grazie @paolo.giannelli, ma non sono convinto sia la strada giusta.
Secondo quanto rilevo io, la presenza di una collection non legata a fk e senza master query non è una situazione anomala, perché la stessa può essere usata popolandola runtime.
Invece, l’utilizzo della funzione loadCollectionFromDb su una collection con queste caratteristiche non dovrebbe essere permessa, perché sbagliata in tutti i contesti.
Ed è qui che chiedo il parare della community: ho visto giusto o mi sono perso un pezzo? 
Penso che la proposta di modifica che intende Paolo sia in linea con quanto hai indicato tu nel primo post ovvero “se uso la loadCollectionFromDb su una collection non collegata ad FK vorrei che il compilatore mi avvisasse della situazione con un warning da confermare”.
Corretto Paolo?
1 Mi Piace
@stefano.masiero è corretto, probabilmente mi sono spiegato male.
@r.bianco dice che in ogni caso debba essere un errore bloccante e potrebbe essere anche corretto così.
1 Mi Piace
Interessante.
In pratica abbiamo due situazioni:
- La presenza di una collection non legata a fk e senza master qry.
- L’utilizzo della funzione loadCollectionFromDb su una collection di questo tipo.
Secondo quanto è stato detto finora, forse la soluzione corretta è quella di emettere un warning con richiesta di conferma nel primo caso, e bloccare del tutto la seconda.
2 Mi Piace
@r.bianco mi sembra la proposta corretta, la voto!
1 Mi Piace
Inserita proposta PRP000673 nel CRM,
grazie della collaborazione 
1 Mi Piace
A questo punto andate tutti a votare la proposta di @r.bianco !
Buongiorno a tutti, dico umilmente la mia.
Ho aperto a caso un progetto “medio”, lanciato la compilazione, e contato circa 180~200 warning, per la maggiore direi inutili, molti concettualmente scorretti (es: mi invitano a cancellare parametri inutilizzati di funzioni in override, se lo facessi l’override smetterebbe di funzionare, crippando l’intero programma)
Un warning in più passerebbe certamente inosservato come gli altri, escludendo il caso in cui venga reso bloccante, e necessiti di conferma per proseguire la compilazione.
Ora, sicuramente questa modifica non darebbe fastidio… però perdonatemi, mi viene da pensare questo: inde è un prodotto straordinario, ma presenta anche lacune, problemi ed obsolescenze che se venissero risolti farebbero una differenza enorme.
E noi non dovremmo “giocarci” il nostro potere contrattuale con progamma sollevando questioni come queste, che sono a mio avviso dei peli nell’uovo.
E non mi metto adesso a fare esempi, perché rischierei di spostare il focus della osservazione.
Riguardo al problema specifico, rispondo sempre con una considerazione generale: INDE propone tantissimi automatismi che si sviluppano all’interno della struttura dei suoi progetti: è normale che molti di questi abbiano comportamenti arbitrari o discutibili, semplicemente perché non sono allineati alle nostre esigenze, od a ciò che riteniamo più logico.
Negli anni, ho imparato a “spegnere” tali automatismi (es: eliminando collegamenti alle FK, pannelli master-detail, etc…) affidandomi sempre di più al codice, che peraltro con INDE è un piacere scrivere. La qualità ed il controllo sui miei progetti è migliorato moltissimo.
Come anche le performance, avendo eliminato una marea di ops inutili, sopratutto I/O su db.
Peace and love and buon lavoro a tutti!
Rispondo per punti:
Il warning proposto è bloccante, e lo scopo è quello di chiedere conferma allo sviluppatore di una situazione non propriamente scorretta ma anomala, che potrebbe portare a problemi.
Non sono d’accordo con questo approccio, perché presuppone che tutti utilizzino InDe nello stesso modo, sfruttando le stesse potenzialità, mirando agli stessi obiettivi. Non è così.
Uno degli scopi di questa discussione era proprio quello di capire se è una mia esigenza o un problema intrinseco di InDe.
Penso che convenga aprire un altro topic e non proseguire su questo.
In ogni caso, grazie della condivisione
Figurati, grazie a te.
Però ribadisco: a mia memoria, negli anni passati, molte volte mi sono trovato perplesso sugli automatismi riguardo le collection, ad esempio il fatto che venissero fatti caricamenti dati arbitrari (e dover mettere una pioggia di loaded=true). Alla fine, ho trovato più razionale quanto dicevo, esplicitare le query, settare le coll sempre transient, rimuovere FK etc, usare il codice per gestire il tutto.
Sono ragionevolmente certo che tu abbia ragione su quanto hai osservato nel primo post. Se vogliamo mettere questo warning, e sia, male non farà.
Resto dell’idea che dovremmo confrontarci meglio tra di noi utenti per mettere a fuoco modifiche più desiderabili, e non disperderci. Il crm a mio avviso è uno strumento troppo caotico, e poco adatto al confronto/discussione
@theguru penso che si cominci a capire quali categorie servano agli argomenti di questa community ed una è quella dei miglioramenti Instant Developer e gestiamo un argomento per ogni miglioramento.
1 Mi Piace