mercoledì 6 maggio 2015

Sviluppare con i Dataset


Prodataset è una della migliori implementazioni realizzate da Progress, da quando l'appserver è stato introdotto nel suo framework di sviluppo.
Il vantaggio principale consiste nella possibilità di incapsulare dati, relazionali o no, e di condividerli attraverso procedure.

Tips & Tricks.

1) Definire le temp-table all'interno di include evitando di usare la specifica LIKE
LIKE permette di ereditare le eventuali modifiche al database; tuttavia ciò impedisce di usare il PDS con un altro database. Creare un PDS indipendente dal database permette di essere usato in modo trasversale da diversi client. Non tutte le modifiche al database, per motivi di business, devono o possono essere inserite in un PDS. Infine, definire un'include per ogni TT, permette il riuso delle TT stesse indipendentemente dal PDS.

2) Limitare il passaggio dati attraverso appserver ed uso di NO-UNDO
Una buona soluzione è quella di usare un secondo PDS su cui copiare le righe modificate, usando il metodo GET-CHANGES, da passare attraverso appserver. L'uso di NO-UNDO permette, in caso di errore, di evitare la roll-back delle TT.

3) Usare PDS permette di ridurre il numero di parametri
Il vantaggio di usare PDS permette di limitare il numero di parametri passati tra procedure. Permette inoltre di aggiungerne o eliminarne in modo semplice, senza creare mismatch di parametri. Per esempio possiamo creare un PDS realizzato su una TT contenente i diversi parametri da passare ed una TT contenente i messaggi applicativi e di sistema.

4) Passare un PDS
Passare, come parametro, un dataset handle permette di ottenere dei vantaggi. Consente di implementare codice dinamico, permetter di passare diversi dataset attraverso un handle.

5) Passare PDS e TT by reference/bind ogni volta possibile
Questo permette di condividere PDS e TT attraverso procedure avendo un'unica istanza all'oggetto. Ciò permette un risparmio di risorse nel passaggio parametri.

6) Considerare attentamente quale modalità adottare con il metodo FILL()
Il metodo FILL() permette di "riempire" i PDS con i dati definiti attraverso le TT, i data-source, le query e le relations definite. Il valore di default è MERGE (un nuovo record viene aggiunto se non esiste sulla base del TT unique primary index). Conoscere il funzionamento del metodo FILL è
essenziale nella progettazione di procedure basate su PDS. Altri possibili valori sono APPEND, EMPTY, NO-FILL, REPLACE.

7) DATA-SOURCE
Definire un data-source e lasciare che il metodo FILL risolva le query.

8) Aggiungere un'include, standard, ad ogni TT includendo il database rowid
Il contenuto dell'include può essere, per esempio, il seguente
/* idbrowid.i */
FIELD dbRowid AS CHARACTER
FIELD lastTime AS INTEGER
INDEX dbRowid dbRowid.

Il campo dbRowid contiente il rowid del data-source record. Il rowid è popolato allo scatenarsi di ogni metodo fill and save. E' usato per il repositioning all'interno della query sul db in occorrenza di un refresh.
Il campo lastTime indica il momento in cui i dati sono ritornati dalla query e può essere associato per eventuali trigger di refresh.
L'indice dbRowid  permette di accedere, se noto, più velocemente ai dati.

9) Usare SELF per identificare il TT buffer in una row callback procedure
Se vengono implementate procedure callback dinamiche, è possibile identificare il TT buffer attraverso l'uso di SELF:HANDLE.

PROCEDURE TTAfterRowFill:
DEFINE INPUT PARAMETER DATASET-HANDLE phDataset.

DEFINE VARIABLE hTTbuffer AS HANDLE NO-UNDO.

hTTbuffer = SELF.

10) Ricordarsi set on e set off TRACKING-CHANGES anche lato server
Un problema in cui si può incappare comunemente è dimenticarsi di settare correttamente l'attributo in questione quando si sta usando una AFTER-IMAGE TT. In questa condizione ricordarsi di settare l'attributo al valore TRUE prima di operare le modifiche alla TT e di settarlo uguale a FALSE dopo.

11) Svuotare PDS quando viene popolato all'interno di procedure persistenti
Il concetto si spiega da solo. Essendo l'oggetto istanziato in memoria è valido fintanto che non viene deallocato. Spetta allo sviluppatore eseguire una EMPTY del PDS.

12) Assicurarsi che dopo l'esecuzione del metodo SAVE-ROW-CHANGES() i dati siano corretti
Il metodo in questione assicura il refreshing del buffer con i valori correnti provenienti dal data-source. Il PDS può contenere, per esempio, dei calculated fields o, come visto precedentemente campi (dbRowid) popolati a livello di FILL time. Affinchè il PDS sia coerente si può
customizzare l'evento AFTER-ROW-FILL.

Questa breve guida è da intendersi come un primo passo verso lo sviluppo con i datasets. Non vuole sostituirsi ai manuali forniti da Progress Software, che devono essere usati per lo studio e la comprensione non solo dei  PDS. Lo scopo è fornire un'esperienza di uso e di regole che adotto quando mi trovo a programmare con i PDS.

0 commenti: