Mi inserisco nella discussione per chiedere una cosa veramente banale. Una volta attivati i recursive trigger e le foreign_keys su un database, questi rimangono attivi per quel determinato DB e solo per quello, o devo riattivarli ad ogni nuova connessione, o ancora peggio rimangono attivati su tutti i DB ?
Immagino che il comportamento corretto sia il primo, ma giusto per sicurezza.... grazie Il giorno 21 febbraio 2014 09:54, <a.furi...@lqt.it> ha scritto: > On Fri, 21 Feb 2014 09:23:49 +0100, Andrea Peri wrote: > >> Ho dato una lettura al documento che indicavi. >> >> Riassumendo: >> prima della sqlite 3.6.18 i trigger ricorsivi non erano supporti e >> quindi vanno eviate versioni di sqlite cosi' vecchie. >> >> Nelle versioni successive, pero' i trigger ricorsivi erano >> disabilitati by-default, ppunto come dicevi te. >> Quindi occorre sempre inserire una clausola >> >> PRAGMA recurvive_triggers=1 >> >> Usando gli applicativi di spatialite: >> CLI e Spatialite-GUI. >> Questa clausola >> recursive_triggers va settata comunque o è implicita ? >> >> > con tutte le versioni attuali (CLI/GUI) e' sempre disabilitata > by default; ma per analogia con quanto gia' implementato per > l'analoga "PRAGMA foreign_keys" presumo invece che sarebbe piu' > opportuno abilitarla implicitamente. > > > > Detto questo. >> >> se un disgraziato lavora su QGIS, editando un dataset tramite la >> finestra degli attributi, oppure trmaite le form customized che ora >> qgis consente, tale clausola "recursive_triggers=1" probabilmente è a >> 0 , ma come puo' fare per garantirsi di settarla a 1 ? >> >> > vista l'architettura SQLite, gestire questo tipo di PRAGMA ricade > sotto la piena responsabilita' del sw che attiva la connessione: > non c'e' nessun modo per renderele permanenti. > > il problema e' abbastanza facile da affrontare per tutti i tools che > gestiscono le connessioni in modo centralizzato (p.es. il data-provider > di QGIS, oppure i tool spatialite); ma nel caso p.es. dei plug-in Python > ciascun singolo plug-in e' ovviamente libero di comportarsi come meglio > crede, e non c'e' nessuna possibilita' di imporre dall'esterno un > set di comportamenti predefiniti. > > > > Qui mi sorge un dubbio serio... >> >> E forse comincio a capire perche' a suo tempo ebbi dei problemi... >> >> > N.B.: ed a questo proposito a me inizia a sorgere anche un ulteriore > dubbio; con tutta la proliferazione di tools e di interfacce che > iniziano a circolare, siamo sempre sicuri che il supporto per i vincoli > relazionali venga attivato in tutti i casi ? > > perche' se da qualche parte c'e' un tool che apre una connessione per > conto proprio al di fuori del data-provider (p.es. in Python) che non > cura di impostare correttamente questo parametro di connessione: > > PRAGMA foreign_keys=1 > > allora potrebbe addirittura accadere che tutti i vincoli Primary/Foreign > Key possano venire allegramente violati senza nessuna conseguenza. > e naturalmente, in caso di mancata attivazione, non funzionano neppure > le sequenze di eventi ON CASCADE ... insomma, le conseguenze potrebbero > anche avere un impatto fortemente negativo, anche peggiore di quello > dovuto a mancata attivazione del supporto ricursivo per i triggers. > > > ciao Sandro > _______________________________________________ > Gfoss@lists.gfoss.it > 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. > 666 iscritti al 22.7.2013 >
_______________________________________________ Gfoss@lists.gfoss.it 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. 666 iscritti al 22.7.2013
