2 Dicembre - 12 Dicembre¶
La struttura della di sw_MOVIMENTAZIONE e sue relazioni è stata spiegata il 2 Dicembre
Il 5 dicembre ho messo questo task nel gestore di progetto.
Durante la settimana dall'8 dicembre al 11 dicembre, ho implementato una stored procedure che esportava i movimenti e i dettagli di arrivo, partenza, stato, e mezzo di ingresso, tramite una stored procedure con join alla tabella a_TIPOINOUT, come pensavo che fosse necessario.
Questo tentativo è fallito per la quantità di dati esportati, e la necessità di filter dei dati.
Ma erano corretti il controller e il model nel servizio REST, per entrypoint /Infos/Movements
Il giorno 11 dicembre (sera, ore 19) mi è stato detto di usare una view per movimentazioni.
Grazie alla view il grosso del lavoro dell'estrazione dati e definizione della query era risolto.
Il giorno 12 dicembre ho adattato il controller e model per l'entrypoint REST /Infos/Movements
Le problematiche affrontate durante l'implementazione sono state:
- numero di parametri trattati nella request ed inviati al backend db (codice C#)
- logica di filtering ed implementazione della stored procedure
- Testing con input di filtraggio efficace. (test case definiti ma non registrati)
- Deployment dell'applicazione sul sito di test
Considerazioni¶
- si può migliorare il modo col quale si definiscono test case, senza dover chiedere ogni volta "come faccio la prova?"
- si potrebbero automatizzare i test, nel caso che il codice del servizio, o il codice della/e stored procedure, dovessero cambiare
- il deployment è macchinoso e ripetitivo. Al tempo stesso è poco frequente, quindi tendo a scordarmi i passi necessari per fare il deploy a mano. (devo scrivere esplicitamente i passi nel gestore di progetti)
- la logica dei dati, cosa si può esportare cosa no, cosa serve cosa no, non mi sono ben chiari, e neppure tutte le relazioni presenti a sistema. (devo chiedere più feedback e controllare)
Risultati (funzionalità)¶
/Infos/Movements filtri:
- vin
- origine
- destino
- idgruppoO : gruppo origine
- idgruppoD : gruppo destino
- tipodata : selettore data, ARRIVATO o USCITO
- datafrom: da data
- datato: a data
Dati esportati:
- Stato: PREVISTO, GIACENTE, USCITO, ARRIVATO
- vin
- DesModello
- Origine
- Destino
- DataProgrammazioneDATA
- DataDisponibilitaDATA
- idGruppoO
- idGruppoD
- Lotto
- datainDATA
- DataOUTDATA
- DataPOD
- Cliente
Problema mole di dati e paginazione¶
Filtri troppo laschi possono produrre una quantità enorme di dati.
La paginazione in ambito REST può essere implementata
- in modo puro: nel payload si specifica: page_nr, page_size. Per ogni richiesta: è sessionless come specifica REST
- usando una session con scadenza:
- alla prima richiesta si registra il payload in un db key-value (redis), e si genera un sessionid. key è sessionid, value è: payload di filtering, elementi per pagina.
- la prima richiesta restituisce i valori in un array, ed un metainfo contenente il sessionid
- le richieste per le pagine successive come payload hanno: sessionid, page_nr
- si usa sessionid per interrogare il key-value db (redis), e una prepared con parametri numero di pagina per interrogare il dbms
In quali casi è meglio usare la session con scadenza: ottimizzazioni interne
- Architettura specifica
- esecuzione predittiva del retrievement dei dati
- accesso al dbms limitato da traffic shaping: caricamento dei dati da dbms (relazionale) e storage su key-value db (redis) per poter fornire le pagine successive senza disturbare il relazionale
Quanto è complesso implementare sessionid? è complesso, discretamente.
Chi usa sessionid con scadenza: Amazon Merchant, eBay.
Quanto è opportuno? Non lo so, non credo.
Updated by