esempio Trigger semplice

[Falz]

Ciao a tutti,
non so quasi niente di triggers, ma desidero condividere la conoscenza di un semplice esempio di trigger.
In questo esempio si tratta del calcolo automatico della lunghezza di polilinee ogni qualvolta se ne disegnino di nuove oppure aggiornando un solo vertice.
In questo modo non dovrete più preoccuparvi di lanciare manualmente ogni volta il calcolo delle lunghezze!
In pratica si devono creare due triggers: insert e update.
Testato su Spatialite. Enjoy!

Es:
[
CREATE TABLE ril_lunghezze
(pk INTEGER NOT NULL PRIMARY KEY,
indirizzo TEXT,
lunghezza DOUBLE,
note TEXT);

SELECT AddGeometryColumn('ril_lunghezze','geom',32632,'LINESTRING',2);

CREATE TRIGGER insert_calc_length AFTER INSERT ON ril_lunghezze
BEGIN
UPDATE ril_lunghezze
SET
lunghezza= ROUND(ST_LENGTH(geom), 2)
WHERE ROWID=NEW.ROWID;
END

CREATE TRIGGER update_calc_length AFTER UPDATE ON ril_lunghezze
BEGIN
UPDATE ril_lunghezze
SET
lunghezza= ROUND(ST_LENGTH(geom), 2)
WHERE ROWID=NEW.ROWID;
END
]
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

[a.furieri]

On Thu, 14 Dec 2017 18:18:36 +0100 (CET), [hidden email]
wrote:

> Ciao a tutti,
> non so quasi niente di triggers, ma desidero condividere la
> conoscenza di un semplice esempio di trigger.
> In questo esempio si tratta del calcolo automatico della lunghezza di
> polilinee ogni qualvolta se ne disegnino di nuove oppure aggiornando
> un solo vertice.
> In questo modo non dovrete più preoccuparvi di lanciare manualmente
> ogni volta il calcolo delle lunghezze!
> In pratica si devono creare due triggers: insert e update.
> Testato su Spatialite. Enjoy!
>
> Es:
> [
> CREATE TABLE ril_lunghezze
> (pk INTEGER NOT NULL PRIMARY KEY,
> indirizzo TEXT,
> lunghezza DOUBLE,
> note TEXT);
>
> SELECT
> AddGeometryColumn('ril_lunghezze','geom',32632,'LINESTRING',2);
>
> CREATE TRIGGER insert_calc_length AFTER INSERT ON ril_lunghezze
> BEGIN
> UPDATE ril_lunghezze
> SET
> lunghezza= ROUND(ST_LENGTH(geom), 2)
> WHERE ROWID=NEW.ROWID;
> END
>
> CREATE TRIGGER update_calc_length AFTER UPDATE ON ril_lunghezze
> BEGIN
> UPDATE ril_lunghezze
> SET
> lunghezza= ROUND(ST_LENGTH(geom), 2)
> WHERE ROWID=NEW.ROWID;
> END
> ]
>

Bravo Simone,

hai visto che scrivere un trigger e' tutto sommato facile ?
ed e' uno strumento molto potente, che se viene usato bene
e nel modo corretto puo' consentire di implementare buona
parte della business logic specifica del processo direttamente
dentro al DBMS.

un possibile miglioramento / ottimizzazione:

CREATE TRIGGER update_calc_length
     AFTER UPDATE OF geom ON ril_lunghezze

- come l'hai scritto tu il trigger scattera' inesorabilmente
   per ogni UPDATE; ma se la geometria e' sempre quella di prima
   e' un inutile perditempo.
- se invece lo definisci come "AFTER UPDATE OF geom" il
   trigger scattera' solo quando serve realmente, e cioe'
   quando la geometria risulta effettivamente modificata.


infine una domanda (ma giusto per curisita'): perche'
usi la ROUND() ?
capisco che lo scopo e' quello di arrotondare le lunghezze
con due sole cifre decimali, ma cosi' rischi di alterare
un po' troppo pesantemente i dati.
forse e' meglio se registri le lunghezze con tutti i
decimali possibili, e magari arrotondi a due decimali
quando poi vai ad interrogare. esempio:

SELECT Sum(lunghezza) FROM ril_lunghezze;

oppure

SELECT Round(Sum(lunghezza), 2) FROM ril_lunghezze;

con la seconda arrotondi il totale finale, e quindi
non introduci scostamenti significativi dal valore
reale.
invece con la prima rischi che la somma di tanti
valori arrotondati a monte vada ad amplificare
gli scostamenti.
a lume di naso sarebbe meglio evitare di arrotondare
tutte le volte che scatta il trigger.

ciao Sndro




_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

[Massimiliano Moraca]

Sti trigger mi stanno inTRIGGando :P
Con un trigger è possibile anche tenere traccia dell'evoluzione temporale
di un vettore? Ad esempio poligoni creati, modificati, cancellati..?

Mi indicate una risorsa da cui studiare? Anche un libro se non c'è nulla
online...

Il giorno 14 dicembre 2017 18:50, <[hidden email]> ha scritto:

> On Thu, 14 Dec 2017 18:18:36 +0100 (CET), [hidden email] wrote:
>
>> Ciao a tutti,
>> non so quasi niente di triggers, ma desidero condividere la
>> conoscenza di un semplice esempio di trigger.
>> In questo esempio si tratta del calcolo automatico della lunghezza di
>> polilinee ogni qualvolta se ne disegnino di nuove oppure aggiornando
>> un solo vertice.
>> In questo modo non dovrete più preoccuparvi di lanciare manualmente
>> ogni volta il calcolo delle lunghezze!
>> In pratica si devono creare due triggers: insert e update.
>> Testato su Spatialite. Enjoy!
>>
>> Es:
>> [
>> CREATE TABLE ril_lunghezze
>> (pk INTEGER NOT NULL PRIMARY KEY,
>> indirizzo TEXT,
>> lunghezza DOUBLE,
>> note TEXT);
>>
>> SELECT AddGeometryColumn('ril_lunghezze','geom',32632,'LINESTRING',2);
>>
>> CREATE TRIGGER insert_calc_length AFTER INSERT ON ril_lunghezze
>> BEGIN
>> UPDATE ril_lunghezze
>> SET
>> lunghezza= ROUND(ST_LENGTH(geom), 2)
>> WHERE ROWID=NEW.ROWID;
>> END
>>
>> CREATE TRIGGER update_calc_length AFTER UPDATE ON ril_lunghezze
>> BEGIN
>> UPDATE ril_lunghezze
>> SET
>> lunghezza= ROUND(ST_LENGTH(geom), 2)
>> WHERE ROWID=NEW.ROWID;
>> END
>> ]
>>
>>
> Bravo Simone,
>
> hai visto che scrivere un trigger e' tutto sommato facile ?
> ed e' uno strumento molto potente, che se viene usato bene
> e nel modo corretto puo' consentire di implementare buona
> parte della business logic specifica del processo direttamente
> dentro al DBMS.
>
> un possibile miglioramento / ottimizzazione:
>
> CREATE TRIGGER update_calc_length
>     AFTER UPDATE OF geom ON ril_lunghezze
>
> - come l'hai scritto tu il trigger scattera' inesorabilmente
>   per ogni UPDATE; ma se la geometria e' sempre quella di prima
>   e' un inutile perditempo.
> - se invece lo definisci come "AFTER UPDATE OF geom" il
>   trigger scattera' solo quando serve realmente, e cioe'
>   quando la geometria risulta effettivamente modificata.
>
>
> infine una domanda (ma giusto per curisita'): perche'
> usi la ROUND() ?
> capisco che lo scopo e' quello di arrotondare le lunghezze
> con due sole cifre decimali, ma cosi' rischi di alterare
> un po' troppo pesantemente i dati.
> forse e' meglio se registri le lunghezze con tutti i
> decimali possibili, e magari arrotondi a due decimali
> quando poi vai ad interrogare. esempio:
>
> SELECT Sum(lunghezza) FROM ril_lunghezze;
>
> oppure
>
> SELECT Round(Sum(lunghezza), 2) FROM ril_lunghezze;
>
> con la seconda arrotondi il totale finale, e quindi
> non introduci scostamenti significativi dal valore
> reale.
> invece con la prima rischi che la somma di tanti
> valori arrotondati a monte vada ad amplificare
> gli scostamenti.
> a lume di naso sarebbe meglio evitare di arrotondare
> tutte le volte che scatta il trigger.
>
> ciao Sndro
>
>
>
>
>
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 801 iscritti al 19/07/2017
>

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

[a.furieri]

On Thu, 14 Dec 2017 22:19:25 +0100, Massimiliano Moraca wrote:
> Sti trigger mi stanno inTRIGGando :P
> Con un trigger è possibile anche tenere traccia dell'evoluzione
> temporale di un vettore? Ad esempio poligoni creati, modificati,
> cancellati..?
>

Massimiliano,

certo che puoi; i triggers sono un meccanismo universale,
ci puoi fare qualsiasi cosa che ti viene in mente
(o quasi ...)

l'unico limite e' la tua capacita' creativa di saperti
"inventare" un buon modello dati; naturalmente serve
anche una base molto solida di conoscenza teorica su
SQL con tutte le sue estensioni Spatial, cosi' come e'
indispensabile quella certa "praticaccia spicciola" che
si acquisisce solo a forza di lavorare sul campo imparando
piu' che altro dai propri errori.

giusto per analizzare per sommi capi il tuo esempio
relativo all'evoluzione storica dei dati, e' molto
piu' semplice di quanto tu possa credere:

1. ti crei una tavola di appoggio in cui andrai a
    registrare tutte le successive modifiche delle
    tue geometrie. una scelta saggia sarebbe quella
    di introdurre un opportuno vincolo FK che associ
    direttamente ciascuna "riga-versione" con la
    corrispondente riga della tavola-madre.
    cosi' come sarebbe opportuno inserire un timestamp
    che tenga traccia della data-ora in cui e' avvenuta
    la modifica; datti un'occhiata a DateTime('now')

2. a questo punto vai ad installare tre triggers
    sulla tavola-madre, uno per la Insert, uno per
    la Update ed uno per la Delete.
    ovviamente ciascuno di questi non fara' altro
    che prendere la geometria e salvarla permanentemente
    sulla tavola-versioni associandola al timestamp
    corrente.

basta; non serve altro. e' piu' facile da implementare
che da spiegare.


concetti da tenere bene a mente:
================================
un Trigger e' semplicemente un gestore di eventi.
una volta che il Trigger e' correttamente installato
scattera' automaticamente tutte le volte che si
verifica l'evento in oggetto.
l'azione specifica di ciascun Trigger e' determinata
da un "pezzo" di SQL che sta a te scrivere nel modo
che ritieni piu' opportuno; hai tutta la liberta'
che vuoi di fare qualsiasi cosa che ti passi per la
zucca, basta solo che tu trovi il modo di tradurla
in una appropriata sequenza di comandi SQL.
ovviamente liberta' e responsabilita' sono sempre
due facce della medesima medaglia; se non funziona
e' sicuramente colpa tua, e ti dovrai quindi armare
di santissima pazienza per fare tutto il debugging
del caso (che e' poi la vera essenza di qualsiasi
sviluppo sw; un bravo sviluppatore non e' uno bravo
a scrivere codice, e' soprattutto uno bravo a fare
debugging)


> Mi indicate una risorsa da cui studiare? Anche un libro se non c'è
> nulla online...
>

non credo proprio che esista nulla di specifico
relativo ai triggers, al massimo puoi trovare qualche
manuale generico su SQL che avra' un capitoletto
sui meccanismi generali dei triggers.
dovresti sicuramente trovare qualche manuale piu' o
meno ponderoso in qualsiasi libreria universitaria.

per tutto il resto serve tenere sempre sotto mano
la doc tecnica del tuo DBMS preferito [1], ma soprattutto
servono tempo, pazienza e perseveranza, uniti ad un
pizzico di intuizione e di fantasia creativa.

[1] https://www.sqlite.org/lang.html

ciao Sandro


_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

[Andrea Peri]

Ad esempio un esempio di uso che ho tipico di un trigger e' impedire la
modifica dei dati.

Ricordo un vecchio nostro plugin che facemmo realizzare per qgis in cui la
base dati era uno spatialite nelle cui tabelle erano stati inseriti dei
triggers per impedire che l'utente potesse
modificare i dati aprendo un qgis e mettendo lo spatialite in editing. Il
plugin guidava l'utente a eseguire detemrinate modifiche in un certo modo e
solo quelle.
Volevamo garantirci che l'utente non potesse aprire lo spatialite in
autonomia con qgis stesso o con altro software e intervenire sui dati
alterandoli in maniera incontrollata.
Per questo adottammo alcuni triggers che a certe condizioni impedivano la
modifica dei dati.

Altro esempio e' quello di usare un triger per fare la MakeValid della
geometria e garantire quindi la sua correttezza.

Tutto bello.
Pero' attenzione ad aggiungere i triggers.
Il maggior rischio e' pensare di usarli per fare cose troppo sofisticate.

Con il rischio che poiche' non si a mai cosa in futuro ci si deve fare con
tali dati, di ritrovarsi magari dopo qualche mese a vedere comportamenti
anomali su un applicativo e dimenticarsi che dentro la BD vi' sono dei
triggers che facevano certe operazioni e che guarda caso interfericono con
altre operazioni all'epoca non preventivate.

I triggers non sono facilmente rilevabili , e, specialmente su spatialite,
non credo che si possano nemmeno rimuovere senza interferire con i dati
stessi.

Qui pero' forse lo sa' meglio Furieri.
Forse mi sbaglio, ma temo che per rimuovere un trigger su una tabella
spatialite sia necessario droppare la tabella con tutto il suo contenuto.

Se cosi' fosse occorre stare parecchio attenti a usarli , perche' se per
rimuovere un trigger che da noia si deve cancellare tutti i dati in tale
tabella.
Si fa' certamente, ma diventa macchinoso e complicato .

Quindi attenzione, massima attenzione a usare i triggers.


A.


Il giorno 15 dicembre 2017 00:40, <[hidden email]> ha scritto:

> On Thu, 14 Dec 2017 22:19:25 +0100, Massimiliano Moraca wrote:
>
>> Sti trigger mi stanno inTRIGGando :P
>> Con un trigger è possibile anche tenere traccia dell'evoluzione
>> temporale di un vettore? Ad esempio poligoni creati, modificati,
>> cancellati..?
>>
>>
> Massimiliano,
>
> certo che puoi; i triggers sono un meccanismo universale,
> ci puoi fare qualsiasi cosa che ti viene in mente
> (o quasi ...)
>
> l'unico limite e' la tua capacita' creativa di saperti
> "inventare" un buon modello dati; naturalmente serve
> anche una base molto solida di conoscenza teorica su
> SQL con tutte le sue estensioni Spatial, cosi' come e'
> indispensabile quella certa "praticaccia spicciola" che
> si acquisisce solo a forza di lavorare sul campo imparando
> piu' che altro dai propri errori.
>
> giusto per analizzare per sommi capi il tuo esempio
> relativo all'evoluzione storica dei dati, e' molto
> piu' semplice di quanto tu possa credere:
>
> 1. ti crei una tavola di appoggio in cui andrai a
>    registrare tutte le successive modifiche delle
>    tue geometrie. una scelta saggia sarebbe quella
>    di introdurre un opportuno vincolo FK che associ
>    direttamente ciascuna "riga-versione" con la
>    corrispondente riga della tavola-madre.
>    cosi' come sarebbe opportuno inserire un timestamp
>    che tenga traccia della data-ora in cui e' avvenuta
>    la modifica; datti un'occhiata a DateTime('now')
>
> 2. a questo punto vai ad installare tre triggers
>    sulla tavola-madre, uno per la Insert, uno per
>    la Update ed uno per la Delete.
>    ovviamente ciascuno di questi non fara' altro
>    che prendere la geometria e salvarla permanentemente
>    sulla tavola-versioni associandola al timestamp
>    corrente.
>
> basta; non serve altro. e' piu' facile da implementare
> che da spiegare.
>
>
> concetti da tenere bene a mente:
> ================================
> un Trigger e' semplicemente un gestore di eventi.
> una volta che il Trigger e' correttamente installato
> scattera' automaticamente tutte le volte che si
> verifica l'evento in oggetto.
> l'azione specifica di ciascun Trigger e' determinata
> da un "pezzo" di SQL che sta a te scrivere nel modo
> che ritieni piu' opportuno; hai tutta la liberta'
> che vuoi di fare qualsiasi cosa che ti passi per la
> zucca, basta solo che tu trovi il modo di tradurla
> in una appropriata sequenza di comandi SQL.
> ovviamente liberta' e responsabilita' sono sempre
> due facce della medesima medaglia; se non funziona
> e' sicuramente colpa tua, e ti dovrai quindi armare
> di santissima pazienza per fare tutto il debugging
> del caso (che e' poi la vera essenza di qualsiasi
> sviluppo sw; un bravo sviluppatore non e' uno bravo
> a scrivere codice, e' soprattutto uno bravo a fare
> debugging)
>
>
> Mi indicate una risorsa da cui studiare? Anche un libro se non c'è
>> nulla online...
>>
>>
> non credo proprio che esista nulla di specifico
> relativo ai triggers, al massimo puoi trovare qualche
> manuale generico su SQL che avra' un capitoletto
> sui meccanismi generali dei triggers.
> dovresti sicuramente trovare qualche manuale piu' o
> meno ponderoso in qualsiasi libreria universitaria.
>
> per tutto il resto serve tenere sempre sotto mano
> la doc tecnica del tuo DBMS preferito [1], ma soprattutto
> servono tempo, pazienza e perseveranza, uniti ad un
> pizzico di intuizione e di fantasia creativa.
>
> [1] https://www.sqlite.org/lang.html
>
> ciao Sandro
>
>
>
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 801 iscritti al 19/07/2017
>

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

[Massimiliano Moraca]

Grazie per le indicazioni a tutti e due :)

Il giorno 15 dicembre 2017 08:02, Andrea Peri <[hidden email]> ha
scritto:

>
> Ad esempio un esempio di uso che ho tipico di un trigger e' impedire la
> modifica dei dati.
>
> Ricordo un vecchio nostro plugin che facemmo realizzare per qgis in cui la
> base dati era uno spatialite nelle cui tabelle erano stati inseriti dei
> triggers per impedire che l'utente potesse
> modificare i dati aprendo un qgis e mettendo lo spatialite in editing. Il
> plugin guidava l'utente a eseguire detemrinate modifiche in un certo modo e
> solo quelle.
> Volevamo garantirci che l'utente non potesse aprire lo spatialite in
> autonomia con qgis stesso o con altro software e intervenire sui dati
> alterandoli in maniera incontrollata.
> Per questo adottammo alcuni triggers che a certe condizioni impedivano la
> modifica dei dati.
>
> Altro esempio e' quello di usare un triger per fare la MakeValid della
> geometria e garantire quindi la sua correttezza.
>
> Tutto bello.
> Pero' attenzione ad aggiungere i triggers.
> Il maggior rischio e' pensare di usarli per fare cose troppo sofisticate.
>
> Con il rischio che poiche' non si a mai cosa in futuro ci si deve fare con
> tali dati, di ritrovarsi magari dopo qualche mese a vedere comportamenti
> anomali su un applicativo e dimenticarsi che dentro la BD vi' sono dei
> triggers che facevano certe operazioni e che guarda caso interfericono con
> altre operazioni all'epoca non preventivate.
>
> I triggers non sono facilmente rilevabili , e, specialmente su spatialite,
> non credo che si possano nemmeno rimuovere senza interferire con i dati
> stessi.
>
> Qui pero' forse lo sa' meglio Furieri.
> Forse mi sbaglio, ma temo che per rimuovere un trigger su una tabella
> spatialite sia necessario droppare la tabella con tutto il suo contenuto.
>
> Se cosi' fosse occorre stare parecchio attenti a usarli , perche' se per
> rimuovere un trigger che da noia si deve cancellare tutti i dati in tale
> tabella.
> Si fa' certamente, ma diventa macchinoso e complicato .
>
> Quindi attenzione, massima attenzione a usare i triggers.
>
>
> A.
>
>
> Il giorno 15 dicembre 2017 00:40, <[hidden email]> ha scritto:
>
>> On Thu, 14 Dec 2017 22:19:25 +0100, Massimiliano Moraca wrote:
>>
>>> Sti trigger mi stanno inTRIGGando :P
>>> Con un trigger è possibile anche tenere traccia dell'evoluzione
>>> temporale di un vettore? Ad esempio poligoni creati, modificati,
>>> cancellati..?
>>>
>>>
>> Massimiliano,
>>
>> certo che puoi; i triggers sono un meccanismo universale,
>> ci puoi fare qualsiasi cosa che ti viene in mente
>> (o quasi ...)
>>
>> l'unico limite e' la tua capacita' creativa di saperti
>> "inventare" un buon modello dati; naturalmente serve
>> anche una base molto solida di conoscenza teorica su
>> SQL con tutte le sue estensioni Spatial, cosi' come e'
>> indispensabile quella certa "praticaccia spicciola" che
>> si acquisisce solo a forza di lavorare sul campo imparando
>> piu' che altro dai propri errori.
>>
>> giusto per analizzare per sommi capi il tuo esempio
>> relativo all'evoluzione storica dei dati, e' molto
>> piu' semplice di quanto tu possa credere:
>>
>> 1. ti crei una tavola di appoggio in cui andrai a
>>    registrare tutte le successive modifiche delle
>>    tue geometrie. una scelta saggia sarebbe quella
>>    di introdurre un opportuno vincolo FK che associ
>>    direttamente ciascuna "riga-versione" con la
>>    corrispondente riga della tavola-madre.
>>    cosi' come sarebbe opportuno inserire un timestamp
>>    che tenga traccia della data-ora in cui e' avvenuta
>>    la modifica; datti un'occhiata a DateTime('now')
>>
>> 2. a questo punto vai ad installare tre triggers
>>    sulla tavola-madre, uno per la Insert, uno per
>>    la Update ed uno per la Delete.
>>    ovviamente ciascuno di questi non fara' altro
>>    che prendere la geometria e salvarla permanentemente
>>    sulla tavola-versioni associandola al timestamp
>>    corrente.
>>
>> basta; non serve altro. e' piu' facile da implementare
>> che da spiegare.
>>
>>
>> concetti da tenere bene a mente:
>> ================================
>> un Trigger e' semplicemente un gestore di eventi.
>> una volta che il Trigger e' correttamente installato
>> scattera' automaticamente tutte le volte che si
>> verifica l'evento in oggetto.
>> l'azione specifica di ciascun Trigger e' determinata
>> da un "pezzo" di SQL che sta a te scrivere nel modo
>> che ritieni piu' opportuno; hai tutta la liberta'
>> che vuoi di fare qualsiasi cosa che ti passi per la
>> zucca, basta solo che tu trovi il modo di tradurla
>> in una appropriata sequenza di comandi SQL.
>> ovviamente liberta' e responsabilita' sono sempre
>> due facce della medesima medaglia; se non funziona
>> e' sicuramente colpa tua, e ti dovrai quindi armare
>> di santissima pazienza per fare tutto il debugging
>> del caso (che e' poi la vera essenza di qualsiasi
>> sviluppo sw; un bravo sviluppatore non e' uno bravo
>> a scrivere codice, e' soprattutto uno bravo a fare
>> debugging)
>>
>>
>> Mi indicate una risorsa da cui studiare? Anche un libro se non c'è
>>> nulla online...
>>>
>>>
>> non credo proprio che esista nulla di specifico
>> relativo ai triggers, al massimo puoi trovare qualche
>> manuale generico su SQL che avra' un capitoletto
>> sui meccanismi generali dei triggers.
>> dovresti sicuramente trovare qualche manuale piu' o
>> meno ponderoso in qualsiasi libreria universitaria.
>>
>> per tutto il resto serve tenere sempre sotto mano
>> la doc tecnica del tuo DBMS preferito [1], ma soprattutto
>> servono tempo, pazienza e perseveranza, uniti ad un
>> pizzico di intuizione e di fantasia creativa.
>>
>> [1] https://www.sqlite.org/lang.html
>>
>> ciao Sandro
>>
>>
>>
>> _______________________________________________
>> [hidden email]
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>> dell'Associazione GFOSS.it.
>> 801 iscritti al 19/07/2017
>>
>
>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -----------------
>

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

[a.furieri]

On Fri, 15 Dec 2017 08:02:22 +0100, Andrea Peri wrote:
> Tutto bello.
> Pero' attenzione ad aggiungere i triggers.
> Il maggior rischio e' pensare di usarli per fare cose troppo
> sofisticate.
>

un trigger e' esattamente come un coltello molto affilato;
se lo sai usare bene e con giudizio puo' servire per fare
tante cose utili (per esempio in cucina), ma se lo usi
male e senza criterio puo' finire per ferire anche gravemente
te stesso o gli altri ... ma la colpa non e' mai del coltello,
e' sempre tutta di chi lo maneggia :-D

> Con il rischio che poiche' non si a mai cosa in futuro ci si deve
> fare
> con tali dati, di ritrovarsi magari dopo qualche mese a vedere
> comportamenti anomali su un applicativo e dimenticarsi che dentro la
> BD vi' sono dei triggers che facevano certe operazioni e che guarda
> caso interfericono con altre operazioni all'epoca non preventivate.
>
> I triggers non sono facilmente rilevabili , e, specialmente su
> spatialite,
> non credo che si possano nemmeno rimuovere senza interferire con i
> dati stessi.
>
> Qui pero' forse lo sa' meglio Furieri.
> Forse mi sbaglio, ma temo che per rimuovere un trigger su una tabella
> spatialite sia necessario droppare la tabella con tutto il suo
> contenuto.
>
> Se cosi' fosse occorre stare parecchio attenti a usarli , perche' se
> per rimuovere un trigger che da noia si deve cancellare tutti i dati
> in tale tabella.
> Si fa' certamente, ma diventa macchinoso e complicato .
>

no, su SQLite non ci sono problemi di sorta a rimuovere un trigger;
basta semplicemente eseguire:

DROP TRIGGER <trigger-name>;

una volta rimosso il trigger tutti gli effetti connessi cesseranno
immediatamente. ovviamente i dati gia' presenti nella tavola rimarranno
del tutto inalterati.

il limite di SQLite e' che a differenze di PostgreSQL non supporta
"ALTER TABLE DISABLE TRIGGER", "ALTER TABLE ENABLE TRIGGER" o
"ALTER TRIGGER".
su SQLite l'unico modo per modificare un qualunque trigger gia'
definito e' quello di fare una "DROP TRIGGER" seguita da una
nuova "CREATE TRIGGER".


> Quindi attenzione, massima attenzione a usare i triggers.
>

non posso far altro che associarmi alla raccomandazione di
Andrea; i trigger sono tanto potenti quanto pericolosi, e
quindi vanno maneggiati con estrema cautela e solo dopo
avere effettuato a monte un testing molto pignolo e pedante
a scanso di brutte sorprese.

ciao Sandro
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

[Amedeo Fadini]

Massimiliano, come detto da Sandro la storicizzazione richiede una tabella
di appoggio, se cerchi audit table trovi numerosi esempi, ad esempio

https://github.com/simon-weber/Instant-SQLite-Audit-Trail/blob/master/README.md

Occhio che i dbms danno dipendenza!

amefad


Il 15/dic/2017 09:24 AM, <[hidden email]> ha scritto:

On Fri, 15 Dec 2017 08:02:22 +0100, Andrea Peri wrote:

>
>
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

[Marco]

...e meno male che non ne sapevi quasi niente di Trigger !!!  ;-)

Il 14 Dic 2017 6:26 PM, <[hidden email]> ha scritto:

> Ciao a tutti,
> non so quasi niente di triggers, ma desidero condividere la conoscenza di
> un semplice esempio di trigger.
> In questo esempio si tratta del calcolo automatico della lunghezza di
> polilinee ogni qualvolta se ne disegnino di nuove oppure aggiornando un
> solo vertice.
> In questo modo non dovrete più preoccuparvi di lanciare manualmente ogni
> volta il calcolo delle lunghezze!
> In pratica si devono creare due triggers: insert e update.
> Testato su Spatialite. Enjoy!
>
> Es:
> [
> CREATE TABLE ril_lunghezze
> (pk INTEGER NOT NULL PRIMARY KEY,
> indirizzo TEXT,
> lunghezza DOUBLE,
> note TEXT);
>
> SELECT AddGeometryColumn('ril_lunghezze','geom',32632,'LINESTRING',2);
>
> CREATE TRIGGER insert_calc_length AFTER INSERT ON ril_lunghezze
> BEGIN
> UPDATE ril_lunghezze
> SET
> lunghezza= ROUND(ST_LENGTH(geom), 2)
> WHERE ROWID=NEW.ROWID;
> END
>
> CREATE TRIGGER update_calc_length AFTER UPDATE ON ril_lunghezze
> BEGIN
> UPDATE ril_lunghezze
> SET
> lunghezza= ROUND(ST_LENGTH(geom), 2)
> WHERE ROWID=NEW.ROWID;
> END
> ]
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 801 iscritti al 19/07/2017

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

[Falz]

Innanzitutto ringrazio Furieri per le osservazioni e i consigli (ho imparato qualcosa di nuovo) :)
Nel mio caso, trattasi di una bozza con pochi elementi per il calcolo delle lunghezze.
Giustamente per una cosa professionale, non ci vuole l'arrotondamento.
Tempo fa sul web ho trovato questo sito:
http://northredoubt.com/n/2012/10/19/spatialite-and-triggers-to-update-data/
dal quale ho studiato e modificato il codice a mia necessità.
Grazie a tutti! :)


 

> Message: 2
> Date: Sat, 16 Dec 2017 00:05:20 +0100
> From: Marco Spaziani <[hidden email]>
> To: [hidden email]
> Cc: "GFOSS. it" <[hidden email]>
> Subject: Re: [Gfoss] esempio Trigger semplice
> Message-ID:
>  <[hidden email]>
> Content-Type: text/plain; charset="UTF-8"
>
> ...e meno male che non ne sapevi quasi niente di Trigger !!! ;-)
>
> Il 14 Dic 2017 6:26 PM, <[hidden email]> ha scritto:
>
> > Ciao a tutti,
> > non so quasi niente di triggers, ma desidero condividere la conoscenza di
> > un semplice esempio di trigger.
> > In questo esempio si tratta del calcolo automatico della lunghezza di
> > polilinee ogni qualvolta se ne disegnino di nuove oppure aggiornando un
> > solo vertice.
> > In questo modo non dovrete più preoccuparvi di lanciare manualmente ogni
> > volta il calcolo delle lunghezze!
> > In pratica si devono creare due triggers: insert e update.
> > Testato su Spatialite. Enjoy!
> >
> > Es:
> > [
> > CREATE TABLE ril_lunghezze
> > (pk INTEGER NOT NULL PRIMARY KEY,
> > indirizzo TEXT,
> > lunghezza DOUBLE,
> > note TEXT);
> >
> > SELECT AddGeometryColumn('ril_lunghezze','geom',32632,'LINESTRING',2);
> >
> > CREATE TRIGGER insert_calc_length AFTER INSERT ON ril_lunghezze
> > BEGIN
> > UPDATE ril_lunghezze
> > SET
> > lunghezza= ROUND(ST_LENGTH(geom), 2)
> > WHERE ROWID=NEW.ROWID;
> > END
> >
> > CREATE TRIGGER update_calc_length AFTER UPDATE ON ril_lunghezze
> > BEGIN
> > UPDATE ril_lunghezze
> > SET
> > lunghezza= ROUND(ST_LENGTH(geom), 2)
> > WHERE ROWID=NEW.ROWID;
> > END
> > ]
> >
> > _______________________________________________
> > [hidden email]
> > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> > Questa e' una lista di discussione pubblica aperta a tutti.
> > I messaggi di questa lista non hanno relazione diretta con le posizioni
> > dell'Associazione GFOSS.it.
> > 801 iscritti al 19/07/2017
>
> ------------------------------
>
> Subject: Chiusura del digest
>
> _______________________________________________
> Gfoss mailing list
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non rispecchiano necessariamente
> le posizioni dell'Associazione GFOSS.it.
> 802 iscritti al 30.11.2015
>
> ------------------------------
>
> Fine di Digest di Gfoss, Volume 150, Numero 17
>
> **********************************************

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017